FreeTDS Development Group

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

Hey James,

> The db-lib caller, however, will examine his 32-bit buffer as a 32-bit
int.  In buffer_transfer_bound_data(), I think we all we have to do is treat
the nullbind indicator thus:  
>
>       if (curcol->column_nullbind) {
>               if (tds_get_null(resinfo->current_row, i)) {
>                       *(DBINT*)(curcol->column_nullbind) = -1;
>               } else {
>                       *(DBINT*)(curcol->column_nullbind) = 0;
>               }
>       }

This code change is both correct and necessary. You can apply it now if you
want. I'll include it in my next patch otherwise.

> Whew.  I wonder what exactly "did not specify any data conversions" means?
srctype==desttype?)

I guess it does mean srctype == desttype. 
If you were (implicitly) specifying a data conversion by binding, say, a
datetime column to a char type host variable, and the host varible length
was not sufficient to hold the converted value, you would get an "overflow"
type error out of the conversion function.
This is both legitimate and useful, as it would point a (probable) coding
error on your part.
I guess you could deliberately bind a char column to a char type host
variable that was of insufficient length to hold all the data in the column.
You might want to do this to trim an arbitrary amount of trailing blanks
from the data for example, or legitimately invoke a type of "substring"
functionality.
You can see why this might be regarded as legitimate practice, not meriting
an "overflow" type error.
I can only see this taking effect for CHAR type columns/host variables
though. A DBINT is intrinsically capable of holding the data from an INT
column, and so on...

I'll put the change for this into the code as part of my next patch.

Bill


> -----Original Message-----
> From: Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> Sent: 04 June 2004 22:17
> To:   FreeTDS Development Group
> Subject:      RE: [freetds] what size indicator
> 
> > -----Original Message-----
> > From: freetds-bounces AT lists.ibiblio.org
> > [mailto:freetds-bounces AT lists.ibiblio.org]On Behalf Of 
> > ZIGLIO, Frediano, VF-IT
> > Sent: June 4, 2004 8:51 AM
> > > 
> > > typedef struct tds_column
> > > {
> > > ...
> > >   TDS_SMALLINT *column_nullbind;
> > > ...
> > > } TDSCOLUMN;
> > > 
> > > blk_bind(CS_BLKDESC * blkdesc, CS_INT item, CS_DATAFMT * 
> > > datafmt, CS_VOID
> > > * buffer, CS_INT * datalen, CS_SMALLINT * indicator)
> > > 
> > > dbnullbind(DBPROCESS * dbproc, int column, DBINT * indicator)
> > >                                            ^^^^^
> > 
> > Last Bill patch change the pointer from TDS_CHAR* to TDS_INT *.
> > 
> > >From include/tds.h
> > 
> ...
> > These fields are only used by client libraries (not libTDS) so every
> > library should use as they like. Perhaps an union like
> > 
> >     union {
> >             struct {
> >                     ...
> >             } db;
> >             struct {
> >                     ...
> >             } ct;
> >     } lib;
> > would be better ??
> 
> I don't think it's necessary.  AFAIK:
> 
> 1.  db-lib expects the caller to provide a DBINT buffer.  
> 2.  ct-lib expects the caller to provide a CS_SMALLINT buffer.  
> 
> I think what Bill did is basically right.  ct-lib and libtds use a 16-bit
> buffer, provided by the caller.  The db-lib API requires the user to
> provide a 32-bit buffer that libtds will treat as a 16-bit int.  
> 
> The db-lib caller, however, will examine his 32-bit buffer as a 32-bit
> int.  In buffer_transfer_bound_data(), I think we all we have to do is
> treat the nullbind indicator thus:  
> 
>       if (curcol->column_nullbind) {
>               if (tds_get_null(resinfo->current_row, i)) {
>                       *(DBINT*)(curcol->column_nullbind) = -1;
>               } else {
>                       *(DBINT*)(curcol->column_nullbind) = 0;
>               }
>       }
> 
> (N.B.  There's missing logic here.  Per the docs, the nullbind indicator
> should hold a positive value representing  "The full length of column's
> data, in bytes, if column was bound to a program variable through dbbind,
> the binding did not specify any data conversions, and the bound data was
> truncated because the program variable was too small to hold data for
> column."  Whew.  I wonder what exactly "did not specify any data
> conversions" means?  srctype==desttype?)
> 
> Tell me if that looks good to you, and what happens on the ODBC side.  
> 
> --jkl
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----------------------------------------
> The information contained in this transmission may contain privileged and
> confidential information and is intended only for the use of the person(s)
> named above. If you are not the intended recipient, or an employee or
> agent responsible for delivering this message to the intended recipient,
> any review, dissemination, distribution or duplication of this
> communication is strictly prohibited. If you are not the intended
> recipient, please contact the sender immediately by reply e-mail and
> destroy all copies of the original message. Please note that we do not
> accept account orders and/or instructions by e-mail, and therefore will
> not be responsible for carrying out such orders and/or instructions.
> If you, as the intended recipient of this message, the purpose of which is
> to inform and update our clients, prospects and consultants of
> developments relating to our services and products, would not like to
> receive further e-mail correspondence from the sender, please "reply" to
> the sender indicating your wishes.  In the U.S.: 1345 Avenue of the
> Americas, New York, NY 10105.
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

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

If you are not an intended recipient of this e-mail, please notify
the sender, delete it and do not read, act upon, print, disclose,
copy, retain or redistribute it.

Click here for important additional terms relating to this e-mail.
     <http://www.ml.com/email_terms/>

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