Re: SQL Server version and TDS Version

On Apr 30, 2010, at 1:58 PM, [email protected] 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:[email protected]

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