FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

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