[freetds] freetds ct-lib locale functions
nicholsman at gmail.com
Mon May 28 09:13:04 EDT 2007
> Your patch would be most welcome indeed.
great, I'll see what I can do then!
> Looking at just this part of the dump:
> 0000 ee 00 12 00 01 04 6e 61-6d 65 10 00 00 00 02 af
> ^^^^^ length: 18 bytes
> 0010 00 00 00 50 00 ae 00 01-00 d1 00 00 00 0b 73 65
> ^^ 18th byte
> and the log complains about not knowing what a 0x50 token is. I
> have to
> look at it more closely.
> IIRC the protocol intends the 18 to include the 2-byte size integer
> -- the
> 00 12 -- as part of the 18 bytes. That would put 0x50 on a marker
> boundary i.e. 0x50 would have to be a token denoting a TDS packet
> type ...
> and we know of no such.
> You're telling the server to send utf8 and setting your client as ISO
> 8859-1. Does asking the server for iso_1 help at all?
Everything works fine if I set the encoding to "iso_1" in
freetds.conf. I only get the error when the connection encoding is
set to "utf8". It also works fine if I set it to "iso88592" or
"iso88594" -- I do not get the error. It's strange.
Actually I assume the client settings are UTF-8 also according to my
LANG settings. If I do nothing (do not set the charset = line in
freetds.conf and do not write directly into
tds_login.server_charset), I get the following messages from the
server (my debugging output):
TID 0: server: line:0, severity:11, n:2409: Cannot find the requested
character set in Syscharsets: name = 'UTF-8'.
TID 0: server: line:0, severity:10, n:2411: No conversions will be done.
TID 0: server: line:0, severity:10, n:5704: Changed client character
set setting to '<NULL>'.
TID 0: server: line:0, severity:10, n:5701: Changed database context
so somehow ct-lib is setting the connection encoding to "UTF-8" (from
the UNIX locale) instead of "utf8" (it appears the translation from
UNIX/iconv names -> sybase names is not being done for some reason -
the same problem seems to affect tsql as well). Anyway I'll see what
can find out when I work on the ct-lib locale patch.
> If you have sqsh installed, I'd be interested to know if it
> produces the
> same results. sqsh is a ct-lib application and I've used it with
> TDS 5.0 servers.
OK, I just built sqsh. With Sybase OCS libs, it works fine. sqsh
built with FreeTDS, however gives a similar error message as I
dnichols at barney:~/src/sqsh-2.1.4/src$ ./sqsh -Usa
sqsh-2.1.4 Copyright (C) 1995-2001 Scott C. Gray
Portions Copyright (C) 2004-2006 Michael Peppler
This is free software with ABSOLUTELY NO WARRANTY
For more information type '\warranty'
1> select * from omq_sequences
Open Client Message
Layer 0, Origin 0, Severity 78, Number 52
and then exits...
> Because this is a protocol-level issue, I wouldn't think the
> or even the API would matter; I'd think tsql would show the same
> Yet we talk to Sybase servers all the time, so I'm wonder what
> about this
> particular connection/server is confusing us.
> Thank you for the report. I'll let you know when I've had a chance to
> check the docs against the code. Please try it with tsql and
> iso_1, just
> to try to isolate what's going on.
it does not work with tsql either (this is with charset = utf8 in
freetds.conf, otherwise it works)
dnichols at apollo:~/src/sparc/freetds-0.65.dev.20070523/src/apps$ ./
tsql -Usa -Sbarney
locale is "en_US.UTF-8"
locale charset is "UTF-8"
Msg 5704, Level 10, State 1, Server barney, Line 0
Changed client character set setting to 'utf8'.
1> select * from omq_sequences
Msg 20020, Level 9, State -1, Server OpenClient, Line -1
Bad token from the server: Datastream processing out of sync
The same command works fine with isql -Usa -Sbarney -Jutf8, however...
More information about the FreeTDS