FreeTDS Development Group

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

Guys,

We need to sort out what we're going to do and who's going to do it,
particularly if we're talking about doing a fix in the near future.
For my part I'm happy to write proto-code for how dbconvert() should massage
the target data given the behaviours that I understand. Given a couple days
I can do the same for cs_convert. What we don't need is several people
attempting (possibly conflicting) solutions and then JKL having to sort them
out....

Any mileage in a conference call ? I could try and set one up at ML if you
think it's a good idea...

Bill

> -----Original Message-----
> From: James K. Lowden [SMTP:jklowden AT speakeasy.org]
> Sent: Wednesday, July 10, 2002 2:31 PM
> To:   TDS Development Group
> Subject:      [freetds] RE: Losing last character of TEXT fields
> 
> 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
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')