Skip to Content.
Sympa Menu

freetds - Re: NTEXT support (again)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: NTEXT support (again)
  • Date: Tue, 6 Jun 2000 00:43:37 -0400 (EDT)




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





Archive powered by MHonArc 2.6.24.

Top of Page