FreeTDS Development Group

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

OK I've started to look at this. It looks like we have very similar issues
to those that afflict us with dblib and ctlib data conversions, i.e. exactly
how to return string-type data to the calling program. As with those
interfaces, the programmer clearly has some control over the resulting data
( by specifying the host data type - parameter 3 to SQLBindCol - and a
"destination length" - parameter 5 ).

I've gotten a manual page on SQLBindCol (damn that mixed case!) from MSDN.
For the 5th parameter (buffer or destination length) I have the following:

BufferLength 
        [Input]
        Length of the *TargetValuePtr buffer in bytes. 
        The driver uses BufferLength to avoid writing past the end of the
*TargetValuePtr buffer when returning variable-length data, such as
character or binary data. Note that the driver counts the null-termination
character when returning character data to *TargetValuePtr. *TargetValuePtr
must therefore contain space for the null-termination character or the
driver will truncate the data. 
        When the driver returns fixed-length data, such as an integer or a
date structure, the driver ignores BufferLength and assumes the buffer is
large enough to hold the data. It is therefore important for the application
to allocate a large enough buffer for fixed-length data or the driver will
write past the end of the buffer. 
        SQLBindCol returns SQLSTATE HY090 (Invalid string or buffer length)
when BufferLength is less than 0 but not when BufferLength is 0. However, if
TargetType specifies a character type, an application should not set
BufferLength to 0, because ISO CLI-compliant drivers return SQLSTATE HY090
(Invalid string or buffer length) in that case. 

As you can see, this does not specify what action is to be taken when the
bufferlength is -1 , as in your example. 
My assumption is that this is intended to behave similarly to dblib
interface, i.e. that the value of -1 is valid only for string type host
variables, and it means that the string will be right trimmed of white space
and null terminated. 

Could someone validate this ? Thanks,

Bill 

> -----Original Message-----
> From: Don Burden [SMTP:donb AT zirmed.com]
> Sent: Thursday, July 25, 2002 4:24 PM
> To:   TDS Development Group
> Subject:      [freetds] Still problems with text fields?
> 
> Is there still a bug with length of text fields or am I doing anything
> wrong?
> 
> Using yesterdays nightly build of freeTDS.  Accessing SQL2000 database.
> Here's my code:
> 
>   .....
>   SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
>   SQLBindCol(hstmt, 1, SQL_C_CHAR, sCol1, -1, &cbCol1);
>   SQLExecDirect(hstmt, "SELECT id FROM TEST", SQL_NTS);
>   while(SQLFetch(hstmt)==0)
>     fprintf(stdout, "%s\n", sCol1);
>   .....
> 
> Here is the TEST table:
> 
> id
> ======
> 12345
> 123456
> 1234567
> 123456
> 12345
> 
> If id field is defined as varchar, output is ok:
> 
> 12345
> 123456
> 1234567
> 123456
> 12345
> 
> If id field is defined as text, output is like this:
> 
> 12345
> 12345
> 1234567@
> 1234567@
> 1234567@
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')