Skip to Content.
Sympa Menu

freetds - RE: Losing last character of TEXT fields

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: Losing last character of TEXT fields
  • Date: Wed, 10 Jul 2002 08:52:05 -0400 (EDT)


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





Archive powered by MHonArc 2.6.24.

Top of Page