FreeTDS Development Group

[<camber AT ais.org>]

On Mon, 5 Jun 2000, Bob Kline wrote:

> On Mon, 5 Jun 2000 camber AT ais.org wrote:
> 
> > 
> > Hi Bob,
> > 
> > Thanks for the patches, I'll try to get them merged in tonight.
> > 
> 
> Excellent!  I haven't done any regression testing, but I'm fairly
> confident I didn't break anything for apps not dealing with blob-like
> data.
>
They couldn't possibly break anything not already broken...All checked in
anyway.
 
> > dblib layer should really care about the length.  The application is
> > responsible for ensure 1) there is a max length (in bytes) 2) there is
> > sufficient space for the returning text.  MS must introduce a new binding
> > type to handle unicode right? (Something like NSTRINGBIND instead of
> > STRINGBIND???) Does anyone know what this might be?  I believe ctlib
> > support multichar codes.
> > 
> 
> If Microsoft has introduced a new binding type they went out of their
> way to omit it from the documentation for SQL Server 7.0's programmer
> kit.  That's why I stuck in the stopgap of passing through the
> wide-character string encoding when the binding type was unrecognized.
>
I'm more of a Sybase guy, so I wasn't sure of the current state of
Microsoft's dblib.  Sounds like time for plan B.  I'm always hesitant to
introduce things not in the original API, but this definately sounds like
a situation where it is needed.

> > > 3. I believe I guessed incorrectly about the return value from 
> > >    tds_convert(), thinking that for string values it should represent
> > >    the number of characters.  It seems more likely that it is supposed
> > >    to represent the number of bytes converted for all types.  Haven't
> > >    been able to find the comments documenting what the real answer is.
> > The return from tds_convert() is the size of converted data...ie it
> > includes the null.
> > 
> 
> If that's true, then you'll want to fix the code for tds_convert_text()
> (on which I was partly basing my guess about the intended behavior) --
> its return value excludes the null terminator.
> 
Hmmm...I mis-spoke I guess.  This only applies to char/varchar types and
not text.  text is handling completely differently. Each time text is read
from the server room is allocated and filled, and the column_textsize and
column_textvalue fields are set.  This is because text fields can vary in
size dramatically and it is impossible to make them part of the normal row
buffer.

> > > 4. The upper layers don't provide any way to bind to a wide-character
> > >    string variable, so the destination type comes through as -1 when
> > >    I pass through the data type byte for NTEXT (99).  The real fix 
> > >    for this, of course, is to extend all the upper layers to fill
> > >    this gap, but I'm reluctant to disturb any layers above tds more
> > >    than I have to, so as a stopgap solution, I've added -1 to the
> > >    switch statement in the new tds_convert_ntext() function, preserving
> > >    the 16-bit characters from the original transmission.
> > again, a new bind type is needed.  We need to know if MS has put one it
> > their dblib, otherwise I nominate NSTRINGBIND and NTBNSTRINGBIND.
> > 
> 
> Sounds good to me, unless someone with a better link to the Microsoft
> inner sanctum has access to the secret codes. :->}
> 
Again, we may be able to do better in the ctlib API, but with dblib I
think this is the least damaging.

> Bob
> 

Brian