FreeTDS Development Group

[David Nichols <nicholsman AT gmail.com>]

Hi James,

> 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  
to 'master'.

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  
> Sybase
> 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  
mentioned before:

dnichols@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'
Password:
1> select * from omq_sequences
2> go
Open Client Message
Layer 0, Origin 0, Severity 78, Number 52
Unknown marker

and then exits...

> Because this is a protocol-level issue, I wouldn't think the  
> application
> or even the API would matter; I'd think tsql would show the same  
> result.
> 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@apollo:~/src/sparc/freetds-0.65.dev.20070523/src/apps$ ./ 
tsql -Usa -Sbarney
locale is "en_US.UTF-8"
locale charset is "UTF-8"
Password:
Msg 5704, Level 10, State 1, Server barney, Line 0
Changed client character set setting to 'utf8'.

1> select * from omq_sequences
2> go
name
Msg 20020, Level 9, State -1, Server OpenClient, Line -1
Bad token from the server: Datastream processing out of sync
1>

The same command works fine with isql -Usa -Sbarney -Jutf8, however...

thanks,
David