Re: SQL Server version and TDS Version

On May 16, 2010, at 2:47 PM, Vinh Nguyen wrote:

> On Mon, May 3, 2010 at 2:37 PM, Frediano Ziglio <[email protected]>  
> wrote:
>> Il giorno ven, 30/04/2010 alle 16.30 -0400,  
>> [email protected] ha
>> scritto:
>>> On Fri, Apr 30, 2010 at 02:58:12PM -0400, [email protected]  
>>> wrote:
>>>>
>>>> 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
>>>>
>>>> None of this works today, as you know.
>>>
>>> It works even less now.  I committed changes to tds_alloc_locale()
>>> to get its initial values as I described.  glibc give a free  
>>> backtrace
>>> error.  I'm sure it's right, but I've run out of time.
>>>
>>
>> strdup man, strdup !! :)
>>
>> I think I fixed the problem yesterday...
>
> bsqldb and isql both works for me for v8.0.

By isql I assume you mean fisql?  As far as I can tell, fisql and  
bsqldb do not look at LANG either directly or indirectly (though they  
might if you had a locale.conf set up).  So what happens is that you  
always end up with a client charset of ISO-8859-1.  You could confirm  
that by searching for "conversions for client charset" in the debug  
log for this case as well as for the tsql case.

> However, tsql does not:

The main difference with tsql currently is that it looks at your  
locale and tries to set the client character set according to what it  
finds and in a way that does not let you override it.  I've patched  
that (not yet applied) so overriding works, but it will still default  
to your locale charset.  I've also promised James I'd have a look at  
tds_get_locale(), but I'm not yet confident yet I know exactly how the  
default should work.

One likely scenario is that bsqldb and fisql would become more like  
tsql in defaulting to your locale charset rather than to ISO-8859-1,  
but that would actually make fewer things work in your situation.   
Along with that, I think it would need to prevent you from specifying  
a charset for which there is no known local name.

> $ TDSDUMP=stderr TDSVER=8.0 tsql -S adrc -U USERNAME -P PASSWORD
> locale is "en_US.utf-8"
> locale charset is "utf-8"
> log.c:196:Starting log file for FreeTDS 0.83.dev.20100504
>        on 2010-05-16 12:42:50 with debug flags 0x4fff.
> iconv.c:337:tds_iconv_open(0x1001007b0, utf-8)
> iconv.c:197:local name for ISO-8859-1 is ISO-8859-1
> iconv.c:197:local name for UTF-8 is UTF-8
> iconv.c:197:local name for UCS-2LE is UCS-2LE
> iconv.c:197:local name for UCS-2BE is UCS-2BE
> iconv.c:365:setting up conversions for client charset "utf-8"

As I've said before, I don't think this is a valid character set on  
your system.  Neither the system iconv() nor the one that comes with  
FreeTDS knows how to do conversions to/from utf-8 (but they do with  
UTF-8).  If there has been any explanation on-list of how you can even  
get this setting on Mac OS X, I haven't seen it.  Someone mentioned  
Advanced Settings in Terminal, but I have not been able to choose  
settings there that give me anything lower case in LANG.



________________________________________
Craig A. Berry
mailto:[email protected]

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