FreeTDS Development Group

["Bill Thompson" <thompbil AT exchange.uk.ml.com>]

Thanks for this,

I'm thinking of reworking the convert functionality to nail the known
issues. My approach will be as follows:

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

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

Bill