Re: SQL Server version and TDS Version

On Apr 20, 2010, at 2:33 PM, [email protected] wrote:

> On Tue, Apr 20, 2010 at 01:06:38PM -0700, Vinh Nguyen wrote:
>> On Tue, Apr 20, 2010 at 11:00 AM,  <[email protected]> wrote:
>>>> So what exactly is the issue again? ?Is there a difference  
>>>> betweenOn Tue, Apr 20, 2010 at 01:06:38PM -0700, Vinh Nguyen wrote:
>> Issuing your command with tds version 8.0 specified I get:
>> config.c:202:         server_charset = iso_1
>> config.c:216:         client_charset = ISO-8859-1
>>
>> When I specify "client charset = UTF-8" in my .freetds.conf file, I  
>> get:
>>
>> config.c:479:   client charset = 'UTF-8'
>> config.c:526:tds_config_login: client charset is UTF-8.
>> config.c:202:         server_charset = iso_1
>> config.c:216:         client_charset = UTF-8
>>
>> However, with this, when I use tsql I get:
>>
>> locale is "en_US.utf-8"
>> locale charset is "utf-8"
>> Default database being set to IBADataDictionary
>> Msg 20017, Level 9, State -1, Server OpenClient, Line -1
>> Unexpected EOF from the server
>
> Yes, that's what I meant.  :-/
>
> I think there might be a bug.  I have a Mac but I won't be able
> to look at it for the next few days and I don't want you to
> wonder what happened.
>
> Please post the TDSDUMP log again now that you have that line in your
> freetds.conf.  Also the output of locale(1).
>
> tsql is just reporting the results of nl_langinfo(3).  AFAICT
> that output isn't right: it's reporting an encoding that can't be
> used by iconv(3).  That leads me to think your environment is
> misconfigured.
>
> The "client charset = UTF-8" line in your freetds.conf is supposed to
> override environmental settings such as the LANG variable.  With it,  
> your
> TDSDUMP should not report
>
>  iconv.c:432:tds_iconv_info_init: client charset name "" unrecognized
>
> If TDSDUMP still reports that even with UTF-8 set in your  
> freet.conf, that would
> be a bug.  I vaguely remember discussing this before, but yours  
> would be the
> clearest indication.  (It might even be fixed in CVS HEAD.  Yes,
> we need a release.)


There are two or three bugs.  It's reporting 'client charset name ""  
unrecognized' because it's pulling the name from a structure where the  
name doesn't exist in the case of not being able to find a canonical  
name.  That's an easy fix -- patch attached.

But the real damage is already done during the configuration phase and  
easily reproducible by setting LANG.  Also setting TDSDUMPCONFIG gives  
me this in the output:

config.c:532:   Found section global.
config.c:535:Got a match.
config.c:557:   text size = '64512'
config.c:557:   client charset = 'UTF-8'
config.c:602:tds_parse_conf_section: client charset is UTF-8.
...
config.c:217:Final connection parameters:
...
config.c:230:         client_charset = utf-8
config.c:231:               app_name = TSQL

The relevant bit of tsql.c is:

	/* process all the command line args into the login structure */
	populate_login(login, argc, argv);

	/* Try to open a connection */
	tds = tds_alloc_socket(context, 512);
	assert(tds);
	tds_set_parent(tds, NULL);
	connection = tds_read_config_info(tds, login, context->locale);

where populate_login() retrieves the locale and puts the charset in  
the login structure.  When we pass that structure to  
tds_read_config_info(), it correctly finds the value of the charset in  
freetds.conf, but then the last two things it does before printing its  
status are:

         /* Override config file settings with environment variables. */
         tds_fix_connection(connection);

         /* And finally apply anything from the login structure */
         tds_config_login(connection, login);

So in our case what's in the login structure that we passed in trumps  
what's in the configuration file.  It looks like an environment  
variable would do the same thing.  That seems to be by design and  
probably best left alone.

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().

Bug #3 is why "utf-8" can't be converted to a canonical name -- I  
thought that was one of the valid ones.  I think there is a table  
somewhere but I haven't looked at it yet.

________________________________________
Craig A. Berry
mailto:[email protected]

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

_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds

Index: src/tds/iconv.c
===================================================================
RCS file: /cvsroot/freetds/freetds/src/tds/iconv.c,v
retrieving revision 1.143
diff -p -u -r1.143 iconv.c
--- src/tds/iconv.c	8 Feb 2010 12:16:43 -0000	1.143
+++ src/tds/iconv.c	30 Apr 2010 03:25:12 -0000
@@ -440,12 +440,12 @@ tds_iconv_info_init(TDSICONV * char_conv
 	server_canonical = tds_canonical_charset(server_name);
 
 	if (client_canonical < 0) {
-		tdsdump_log(TDS_DBG_FUNC, "tds_iconv_info_init: client charset name \"%s\" unrecognized\n", client->name);
+		tdsdump_log(TDS_DBG_FUNC, "tds_iconv_info_init: client charset name \"%s\" unrecognized\n", client_name);
 		return 0;
 	}
 
 	if (server_canonical < 0) {
-		tdsdump_log(TDS_DBG_FUNC, "tds_iconv_info_init: server charset name \"%s\" unrecognized\n", client->name);
+		tdsdump_log(TDS_DBG_FUNC, "tds_iconv_info_init: server charset name \"%s\" unrecognized\n", server_name);
 		return 0;
 	}