Freetds 0.82 display diff in varbinary(255+) columns between Sybase (TDS 5.0) and MSSQL (TDS 7.0)

"[email protected]" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
This might be a sqsh problem.  If so, I apologize in advance for
adding noise to this list.

When I execute a simple select against a longer than 255 byte varbinary
column using sqsh compiled with FreeTDS 0.82, I get different display
results when accessing Sybase using TDSVER=5.0 and accessing MSSQL using
TDSVER=7.0.

The MSSQL query displays varbinary data like this:

  0x123456789ABCDEF123456789ABCDEF...

While the Sybase query displays garbage ascii characters whose corresponding
binary value comes from the varbinary column.  Eg., given the above  varbinary
string, the Sybase query would display the garbage characters like "#Eg‰«Í" (ascii
characters whose binary values correspond to 12H, 34H, 56H and so on, I guess)

Looking at the TDS dump files:

For MSSQL with TDS 7.0 it says:

> ct.c:1890:_ct_get_client_type(type 34, user 0, size 64512)
> ct.c:2321:ct_describe() datafmt->datatype = 5 server type 34

For Sybase with TDS 5.0 it says:

> ct.c:1890:_ct_get_client_type(type 225, user 4, size 16200)
> ct.c:2321:ct_describe() datafmt->datatype = 0 server type 225
> ct.c:1434:ct_bind() datafmt count = 1 column_number = 4

Note that TDS 5.0 datatype TDS_LONGBINARY has token value 0xE1 or 255, so
this seems appropriate for the data coming back from Sybase.   While
MSSQL/TDS7.0 is using TDS_IMAGE for this long varbinary columns.

Furthermore, for Sybase with TDS 5.0, it looks like ct_describe is returning
datafmt->datatype=0, which I think corresponds to CS_CHAR_TYPE in the CTLib
cstypes.h file.  So this makes it sound like sqsh is doing what ct_describe
is telling it to do.  But why is ct_describe saying to display a long varbinary
column as a character value?

Can you tell me if this is a problem with FreeTDS? Or CTlib?

Thanks in advance
Ben Slade
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.