FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

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


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

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

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.  

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.  

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

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?  

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.  

+++

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.  

--jkl