Skip to Content.
Sympa Menu

freetds - Re: NTEXT support (again)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Bob Kline <bkline AT rksystems.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: NTEXT support (again)
  • Date: Mon, 5 Jun 2000 09:51:54 -0400 (EDT)


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





Archive powered by MHonArc 2.6.24.

Top of Page