FreeTDS Development Group

[jack brack <jack.brack AT inbox.com>]

>> For this php code:
>>  sybase_connect($user, $pass, $serv, "iso_1")
>> 
>> Why does CT try to connect as UTF-8?
>> 
>> It does the same for this one too:
>> 
>>   sybase_connect($user, $pass, $serv, "iso-8859-1")
>> 
>> but Sybase doesn't recognise the character set.
> 
> What is it you're trying to do?

I'd like to connect to the server using the iso_1 character set initially, 
without TDS trying a different character set first.

Why? Because I'd like to try to have some control over what TDS is doing, 
plus I get a warning about "Failed to map a local name to an object id!" in 
my log otherwise. ("UTF-8" not spelt "utf8" isn't recognised)

> 
> Daniel is right that FreeTDS doesn't convert character data for TDS 5.0
> connections.  It could (with commitment and extensive testing), but it
> shouldn't have to, for the simple reason that Sybase servers should
> DTRT: Sybase has a "Server makes right" policy of sending data to the
> client using the encoding specified by the client.
> 
> The trick, then, is to make sure the server knows the client's encoding.
> That information is included in the TDS 5.0 login packet:
> 
> $ sed -ne '437,445p' src/tds/login.c
>        /* use charset nearest to client or nothing */
>         server_charset = NULL;
>         if (!tds_dstr_isempty(&connection->server_charset))
>                 server_charset =
> tds_dstr_cstr(&connection->server_charset);
>         else
>                 server_charset =
> tds_sybase_charset_name(tds_dstr_cstr(&connection->client_charset));
>         if (!server_charset)
>                 server_charset = "";
>         tds_put_login_string(tds, server_charset, TDS_MAX_LOGIN_STR_SZ);
> /* charset */
> 
> The variable 'connection->server_charset' is read from locales.conf.
> You should see it logged if you use TDSDUMPCONFIG.  The string must be a
> Sybase-recognized charset name.
> 
> I think there's an error somewhere, though, so I'm going to suggest you
> change your locales.conf.  In src/tds/config.c, we read locales.conf
> thusly:
> 
>         } else if (!strcmp(option, TDS_STR_CHARSET)) {
>                 tds_dstr_copy(&connection->server_charset, value);
>                 tdsdump_log(TDS_DBG_INFO1, "%s is %s.\n", option,
> tds_dstr_cstr(
> &connection->server_charset));
> 
> That means we're looking for an attribute string defined by
> TDS_STR_CHARSET:
> 
> $ grep TDS_STR_CHARSET include/*.h
> include/tds.h:#define TDS_STR_CHARSET   "charset"
> 
> No space.  Ouch.  So try changing your locales.conf to:

I copied my example from the lcoales.conf in cvs, which uses a space:
 
"http://cvs.sourceforge.net/viewcvs.py/freetds/freetds/locales.conf?rev=1.5&view=markup

> 
> [default]
>         language = english
>         charset = iso_1
> 

I've amended my copy to match this.

> Turn on TDSDUMPCONFIG to confirm it's being used.
> 
> If no server charset is found, the above login.c code sends a NULL,
> telling the server to use its default encoding.  My guess is that until
> now everyone's been satisfied with that and no one has noticed that
> locales.conf is using the wrong attribute string.

The packet dump shows it's trying to negotiate a UTF-8 connection.
I think this is because LANG=de_DE.TF-8. Unsetting LANG does not help.

So I now have a correct locales.conf file, but I'm still getting a UTF-8 
connection attempt.
I've verified that /etc/freetds/locales.conf is being read using strace.

Any more ideas?

> 
> HTH.
> 
> Apologia: This whole business is messy.  There's no reason on God's
> green earth that your Sybase encoding should be sneaked into
> locales.conf while the Microsoft (libiconv) encoding is in freetds.conf.
> It's poorly documented to boot, because yours truly hasn't understood it
> very well, because it's not very widely used (IMO).  And it's a real
> shame that sybase_connect() sees its 3rd parameter ignored.  That's not
> very nice.

No problem at all, thanks for your help.
Can I do anything to update the locales.conf page in the user guide?

> 
> --jkl
> 
> 
> 
> 
> -----------------------------------------
> The information contained in this transmission may be privileged and
> confidential and is intended only for the use of the person(s) named
> above. If you are not the intended recipient, or an employee or agent
> responsible
> for delivering this message to the intended recipient, any review,
> dissemination,
> distribution or duplication of this communication is strictly prohibited.
> If you are
> not the intended recipient, please contact the sender immediately by
> reply e-mail
> and destroy all copies of the original message. Please note that we do
> not accept
> account orders and/or instructions by e-mail, and therefore will not be
> responsible
> for carrying out such orders and/or instructions.  If you, as the
> intended recipient
> of this message, the purpose of which is to inform and update our
> clients, prospects
> and consultants of developments relating to our services and products,
> would not
> like to receive further e-mail correspondence from the sender, please
> "reply" to the
> sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas,
> New York,
> NY 10105.
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds