FreeTDS Development Group

[Jonathan Monroe <monroej_freetds AT actualtechnologies.com>]

I think I have found an issue with the way the SQL_C_BINARY data type 
is handled in the ODBC code.  Currently, SQL_C_BINARY is mapped to the 
SYBBINARY type in odbc_c_to_server_type() in odbc_util.c.  When a 
varchar column is bound using SQLBindCol to a type of SQL_C_BINARY, a 
subsequent SQLFetch causes a conversion in tds_convert() in convert.c 
as if the varchar column were a SQL Server "binary" type containing hex 
characters (with a leading 0x).

I think this is a misinterpretation of the meaning of the SQL_C_BINARY 
type.  It should not be equivalent to the SQL Server "binary" type - it 
actually means that the raw bytes of the column (whatever the type) 
should be returned in the provided buffer without conversion.  Within 
FreeTDS, the column destination type should be treated like a 
SQL_C_CHAR, but without appending the trailing NULL byte.

Patches to make it work correctly might go a little something like this:

odbc_util.c:  v1.62:
334c334
<               return SYBBINARY;
---
>               return SYBVARCHAR;


convert_tds2sql.c:  v1.37:
243c243
<                       memcpy(dest, ores.ib, cplen);
---
>                       memcpy(dest, ores.c, cplen);
250c250
<               free(ores.ib);
---
>               free(ores.c);


By changing the equivalent SQL type to be SYBVARCHAR instead of 
SYBBINARY, the character copy routines in convert.c are used instead of 
the hex parsing routines used for converting binary fields.  The patch 
to convert_tds2sql.c is required because the character buffer (ores.c) 
is then used instead of the binary buffer(ores.ib).

Am I missing anything (or breaking anything) here?  FWIW, the change 
proposed here would make the code compatible with the MS ODBC driver.

Jonathan Monroe