FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hello David, 

David Nichols wrote:
> I just want to check before I make such a patch that the patch would
> be welcome and that nobody else is already working on this.

Your patch would be most welcome indeed. 

> Note that in my last message where I posted a bug report about getting
> an Unknown marker client error message, I did not use the hack I
> described above to reproduce the error or to generate the tds dump
> file

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?  

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.  

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.  

Regards, 

--jkl