FreeTDS Development Group

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

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*
knew them!  

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
intend.  

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
list:

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?  

Regards, 

--jkl

P.S. Freddy, do you have any idea why we have copy_data_to_host_var()?  I
think we should simply call dbconvert().