freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Frediano Ziglio <freddyz77 AT tin.it>
- To: TDS Development Group <freetds AT franklin.oit.unc.edu>
- Subject: RE: Still problems with text fields?
- Date: 26 Jul 2002 13:13:00 +0200
Il ven, 2002-07-26 alle 10:53, Thompson, Bill D (London) ha scritto:
> 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.
No, it give error calling SQLBind. You cannot pass a value <0.
Time ago I posted a test with MS ODBC and SQL Server.
Char are padded with spaces up to len of Char (not len of destination
buffer). String are always null-terminated (even if truncated), Passing
0 as destlen give no-error. Length returned is the full len (id in db is
"TEST", destlen is 2 it return "T" and a length of 4, not 1) or
SQL_NULL_DATA.
> 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
>
Problem is that convert has not yet fixed. In previous thread you decide
to not terminate char conversion and left to other lib (ctlib, dblib,
odbc) the need to do this. This is not yet true. In tds_convert_any you
always terminate and also handle destlen of -2 and -1 (as dblib).
freddy77
-
Still problems with text fields?,
Don Burden, 07/25/2002
- <Possible follow-up(s)>
- RE: Still problems with text fields?, Thompson, Bill D (London), 07/26/2002
- RE: Still problems with text fields?, Thompson, Bill D (London), 07/26/2002
- RE: Still problems with text fields?, Frediano Ziglio, 07/26/2002
- RE: Still problems with text fields?, Don Burden, 07/26/2002
- RE: Still problems with text fields?, Thompson, Bill D (London), 07/26/2002
- RE: Still problems with text fields?, Thompson, Bill D (London), 07/26/2002
- RE: Still problems with text fields?, Don Burden, 07/26/2002
- RE: Still problems with text fields?, Thompson, Bill D (London), 07/26/2002
Archive powered by MHonArc 2.6.24.