FreeTDS Development Group

[Bob Kline <bkline AT rksystems.com>]

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.

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

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

> > 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. :->}

Bob