Skip to Content.
Sympa Menu

freetds - Re: [freetds] SQL Server version and TDS Version

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Craig A. Berry" <craigberry AT mac.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] SQL Server version and TDS Version
  • Date: Fri, 30 Apr 2010 19:32:25 -0500


On Apr 30, 2010, at 1:58 PM, jklowden AT schemamania.org wrote:

Second I want to clarify what we want to happen. Setting tsql
aside for the moment, the library should find its client
encoding from the following, in declining order of precedence:

1. API call e.g. DBSETLCHARSET().
2. freetds.conf.
3. nl_langinfo(3) /* query using CODESET parameter */
4. setlocale(3) /* query using NULL parameter, split on "." */
5. ISO 8859-1

I think this is pretty close to what tsql does after my patch, but half of it's in the library and half of it's in tsql, which after your post doesn't sound like the best solution.

None of this works today, as you know. Not everyone who's worked
on this project has understood the issues as clearly I as do now.
Including me.

Certainly not me :-).


On the assumption that most applications would not call
setlocale(3) first, tds_get_locale() interrogates $LANG directly.
I now think that is a mistake. If the application cannot be
changed, the admin can (er, should be able to) set the encoding
in freetds.conf.

So, you see, I don't think there's a problem with tsql; the
problem lies in the encoding defaults and overrides.

Kinda makes sense. I was reluctant to dig into the library and question its assumptions without some guidance.

The order of initialization should be something like the above
list in reverse, with later calls overwriting prior results:

1. ISO 8859-1 in tds_alloc_locale()
2. setlocale(3) next in tds_alloc_locale()
3. nl_langinfo(3) next in tds_alloc_locale()
4. freetds.conf in tds_parse_conf_section()
5. accept e.g. DBSETLCHARSET() in tds_config_login()

I think the right fix is going to be to reorder things in tsql.c so it
only puts a charset in the login structure when the user specifies one
explicitly on the command line or, as a last chance, puts the charset
in the connection structure if it's empty after the call to
tds_read_config_info().

I think your -J should just set the login structure
the way DBSETLCHARSET() does.

That is exactly what it does:

case 'J':
charset = strdup(optarg);
break;
. . . .

if (charset) tds_set_client_charset(login, charset);

when it processes the switch, and:

if (tds_dstr_isempty(&connection->client_charset)) {
if (!charset)
charset = "ISO-8859-1";

tds_set_client_charset(login, charset);
tds_dstr_dup(&connection->client_charset,
&login->client_charset);
}

as a last resort when there was no -J and setting up the connection has not set the charset. I believe the latter is actually impossible -- there will always be *something* set, so we just need to make sure that it's chosen appropriately by the library.

Then we need some TLC for
tds_alloc_locale(), and some debugging to verify the assignment
sequence.

I see from your subsequent post that we're starting to get there.
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser





Archive powered by MHonArc 2.6.24.

Top of Page