FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

Brian, 

Trouble is, it's not a small patch in my view.
You can't let tds_convert touch the calling programs destination variables
and hope that the calling API will clean it up afterwards. What if a
destination variable is too small to hold the converted data ?
I think that tds_convert has to return the data to the calling api in some
way without touching the calling programs destination variables. Then the
API should decide how to handle passing the data back to the calling
program.

If we're going to do the latter, we should combine it with a thoroughgoing
review of all the API's taking into account all the possible scenarios that
a badly coded program can throw at us!

Bill 


> -----Original Message-----
> From: Brian Bruns [SMTP:camber AT ais.org]
> Sent: Wednesday, July 10, 2002 1:52 PM
> To:   TDS Development Group
> Subject:      [freetds] RE: Losing last character of TEXT fields
> 
> I agree that a small patch needs to go into 0.60.  tds_convert should 
> simply convert the data and return the size, no termination.  Let the APIs
> 
> add termination, padding or whatever after the fact.
> 
> Brian
> 
> On Wed, 10 Jul 2002, ZIGLIO Frediano wrote:
> 
> > > 
> > > 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."
> > 
> > =================================
> > 
> > ---
> > You are currently subscribed to freetds as: [camber AT ais.org]
> > To unsubscribe, forward this message to
> $subst('Email.Unsub')
> > 
> > 
> 
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')