[freetds] Null Handling of VarChar Columns
James K. Lowden
jklowden at freetds.org
Sun Nov 25 11:18:19 EST 2007
Simon Talbot wrote:
> erc = dbbind(dbproc, c+1, bindtype, -1, (BYTE *) data[c].buffer);
> Which is using -1 as the varlen -- I cannot see a definition of what -1
> as a varlen means anywere, but this would explain why bsqldb exhibited
> the problem in the version of the library we did most of our work with.
Gah! I said the dbbind() rules are arcane, but I thought at least *I*
You're right, and our implementation is wrong: dbbind() accepts a varlen
of 0 to mean "the buffer is big enough, trust me". The vartype governs
padding and null-termination. It's dbconvert() that accepts a destlen of
-1 and -2, to indicate the kind of termination.
Microsoft and Sybase agree on the dbbind() semantics. They don't for
dbconvert(); they define -1 differently and only Sybase defines -2.
(However, IIRC Microsoft's implementation does trim blanks for a destlen
of -1.) We adhere to Sybase semantics -- or, at least, that's what we
This will be a royal pain to fix. The padding and termination
instructions -- as presented through the vartype -- have to be inserted
into the colinfo structure, and dbnextrow() will have to honor those
instructions each time a column is fetched to a bound variable. All
without disturbing the other libraries. Such are the joys.
Thank you for pointing this out. There are now two new items on the TODO
1. Write dbsetnull() and fix the default NULL representations.
2. Change dbbind() to disallow -1 as a varlen.
I suppose you know we also accept patches?
P.S. Freddy, do you have any idea why we have copy_data_to_host_var()? I
think we should simply call dbconvert().
More information about the FreeTDS