FreeTDS Development Group

[ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>]

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

I agree. See also my previous mail (with detail of ODBC).
Can you also explain deeply who dblib work?
What conversion is possible? What value of destlen can be used ?

> 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 not the good place for error message/number. Quite all function
require error/message reporting, TDSSOCKET is best place (see also my
unfinished patch).
Changing param to DBANY require a lot of change...
We want this bug fixed for 0.6 so a smaller change should be made.
But I can't make a patch without knowing all library details.
For example I cannot terminate string in tds_convert if dblib conversion to
DBCHAR do not include terminator... I cannot pad because ODBC never pad...

> 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 
> 
As above, a smaller patch should be made.

freddy77

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================