Skip to Content.
Sympa Menu

freetds - RE: Losing last character of TEXT fields

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: RE: Losing last character of TEXT fields
  • Date: Wed, 10 Jul 2002 14:43:47 -0400


Ok, let me take a crack at this....I'm going to agree with most of the
points.

> > From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> > Sent: July 10, 2002 10:02 AM
> >
> > What we don't need is several people
> > attempting (possibly conflicting) solutions and then JKL
> > having to sort them out....
>
> Quite right about that! So far, I'm 0 for 2. Sorry. That's baseball lingo
> for two failures out of two attempts. At sorting them out, that is.
>
> Here's what I suggest, Bill: You do it. :)
>
> Here are the principles:
>
> 1. tds_convert always gets a positive (or zero) destlen. It never
> terminates, pads, or prevaricates. The API should deal with negative
> destlen values, which are really coded instructions for termination/padding.

We may need to support destlen = -1 (meaning unknown buffer size not the
dblib meaning) because dbconvert() may not know how big the buffer is
either. -2 is right out though. I'm for making tds_convert() *as simple
as possible*

>
> 2. tds_convert may fail, and if it does, the contents of the output
> buffer are undefined. Under no circumstances is tds_convert to
> preserve/restore the output buffer (dest).

Cool.

> 3. tds_convert should return an enumerated type whose meanings are the
> union of all return codes in the APIs.

tds_convert needs to return number of characters actually converted, it's
important to the upper layers. error conditions may be specified by -1,
-2, but I'd question whether we need to actually have multiple errors. The
API's report only FAIL, CS_FAIL, or SQL_ERROR so no further work should be
necessary.

> 4. Any error messages should come from tds_convert, as close to the
> detection as possible, unless the APIs disagree on what should happen (in
> which case the APIs will have to issue the message). tds_convert will not
> know anything about the API and will not distinguish among them.

Error messages should be generated using tds_client_msg(), period. It's
the only place for them to be dealt with in the application anyway.

> If you think any of this is unworkable or suboptimal, please say so.
> Brian's a reasonable guy, after he's had his coffee. For that matter, feel
> free to post your own Principles list, if these are defective.

My only principle is to keep it bone simple. One policy, and let the API
work its magic.

> If you become convinced that termination/padding really should be done in
> tds_convert, here's a scheme that might just work without changing much.
> Right now, SYBCHAR gets several treatments; all other datatypes have
> explicit individual unique rules. We could invent new datatypes, say,
> SYBCHAR_NULL, SYBCHAR_BLANK, SYBCHAR_NOTHANKYOU, each of which had its own
> rule. The API would determine the null/padding rule and call tds_convert
> with the appropriate type. Mind, the API still has to pass a bona fide
> positive destlen to tds_convert, no interpretation allowed. These types
> would exist only in the TDS layer; they would not be available to pass *to*
> dbconvert().

Jim! Truely a cure worse than the disease! ;-)

> As Brian points out, some of the cruft in convert.c owes to its ancestory in
> dblib. Whack it, clean it out and good riddance! Be proud and don't look
> back! (Looking back is what cvs is for.) Make convert.c be what it should
> be, free of old prejudices and biases, and restore its good name to the
> realm!
>
> I think this effort is totally worth it, and I don't think it upsets the
> framework. Handling data is the first job of a database library, and
> handling all datatypes correctly would be a major accomplishment of 0.60.
> Does anyone see a reason to ship 0.60 with known broken datatypes support?

The other problem is that binding details, and original datatypes tend to
not make it into the tds_convert() function. For instance, SQLCHAR ->
SYBCHAR, DBCHAR -> SYBCHAR, CS_CHAR -> SYBCHAR....but binding behaviour
may not be the same for all. There are nuances of types and binding rules
that are difficult to get right inside tds_convert(). If we have to do a
single fixup in the API we should do all fixups in the API, not half and
half like our present situation.

> Thank you for reading this far. I'm almost done.
>
> > Any mileage in a conference call? I could try and set one up
> > at ML if you think it's a good idea...
>
> Yes, if there's disagreement on the above. I can do IRC at home, but that's
> 23:00 your summer time. For that matter, before work, as long as the sun's
> up. I'm at UTC -4 until October.

I'm on opennet #freetds in the evenings alot (middle of the night for Bill
;-)

> +++
>
> ODBC. I'm on record as disliking ODBC, and Bill doesn't use it either. But
> Eric, Freddy, you guys seem to know it quite well. Does the above scheme
> sound good to you, and could you make any needed adjustments to the odbc
> layer where conversions are concerned? I think it's just as important that
> odbc work correctly, personal prejudices aside.

ODBC is simpler to handle than dblib/ctlib if we cover the later, the
former should be easy.

> --jkl




Archive powered by MHonArc 2.6.24.

Top of Page