FreeTDS Development Group

[James K. Lowden <jklowden AT speakeasy.org>]

On Wed, 10 Jul 2002 07:38:51 -0400, "Bill Thompson"
<thompbil AT exchange.uk.ml.com> wrote:
> 
> 1) understand the behaviour of the current functionality within the
> API's. basically our problem lies with returning data to "char" program
> variables, whether that is encapsulated in a "convert" type function or
> as part of a "bind" type function. As you say, each API behaves
> differently, as they take different types of input parameters, and are
> clearly implemented differently. I understand dblib's implementation
> pretty well(with the -1 and -2 "destlen" parameters). I'm currently
> getting to grips with ctlib's behaviours (with its "dest format"
> parameters). Of particular interest are the cases where the destination
> variables or lengths may not be large enough to hold a returned value
> (with or without null termination).
> 
> 2) I'm thinking of implementing it as follows:
> a) change tds_convert() to take in a parameter that roughly maps to the
> current DBANY structure, i.e. something that can hold the converted data
> whatever type it is. I think this structure should also have room for an
> error message/number/etc. to report back any conversion problems.

This is approximately what I suggested as "an alternative" yesterday. 
It's not clear to me that the union of error conditions across APIs is
rich enough to justify a structure to hold a return code.  

As I said yesterday, I think tds_convert has its work cut out for it just
doing the conversion proper.  I think it will be easier to implement and
understand if tds_convert deals with the data and the API libraries deal
with the remainder of the destination buffer (pad/null/whathaveyou). 
Especially because, as you note, the whole question arises only for
SYBCHAR destinations.  Of course, there's no reason the SYBCHAR
postprocessing -- should common requirements exist -- couldn't be
implemented in tds_post_convert() or somesuch.  

But, Bill, I have not studied the question carefully and get a rash when I
deal with ODBC.  How similar their requirements are determines how useful
a common library is.  It's not clear to me how much overlap there is
between dbbind() and dbconvert(), for example, or even between dbbind()
and ctbind().  

> b) change dbconvert/cs_convert/odbc-equivalent functions to call
> tds_convert() passing the structure. On return, each API function can
> decide how to return data to the calling program, depending on the
> parameters passed, or call the API error handler, if appropriate.

Seems to me that the error handler might as well be called on the spot,
when the problem is first detected.  We have the machinery, but
tds/convert.c never uses it.  

> Whaddayareckon ? Its clearly too late to get this into 0.60, so I'll
> work on it in the background if people think that's a good idea. I'm
> sure everyone would like to stamp on these issues once and for all...

One thing you mentioned in passing is -2 as a destlen.  We don't handle
that; I overlooked it last night.  Right now, it will be interpreted as a
(very big) unsigned length, probably not what we want.  :/

As for 0.60, I really would like to be able to say "we handle all
datatypes".  As far as I'm concerned, anything that fits in the current
framework and addresses a datatype issue should be part of the upcoming
release.  The more rigorously datatype handling and conversions are
tested, the better off we'll be.  

I'm going to post another prerelease tonight.  

--jkl