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: Thu, 29 Apr 2010 23:02:36 -0500


On Apr 20, 2010, at 2:33 PM, jklowden AT schemamania.org wrote:

On Tue, Apr 20, 2010 at 01:06:38PM -0700, Vinh Nguyen wrote:
On Tue, Apr 20, 2010 at 11:00 AM, <jklowden AT schemamania.org> 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:craigberry AT mac.com

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

Attachment: charset_report.patch
Description: Binary data




Archive powered by MHonArc 2.6.24.

Top of Page