[ psqlodbc-Bugs-1003103 ] copy_and_convert_field(...) destroys bind info for wide char varchar colum

[ psqlodbc-Bugs-1003103 ] copy_and_convert_field(...) destroys bind info for wide char varchar colum

am 16.04.2007 06:04:23 von noreply

Bugs item #1003103, was opened at 2007-04-15 14:39
You can respond by visiting:
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=10031 03&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Thomas Zehbe (thomasz)
Assigned to: Nobody (None)
Summary: copy_and_convert_field(...) destroys bind info for wide char varchar columns

Initial Comment:
I'm using psqlodbc 08.02.0200 on SuSE Linux 9.3, Postgres 8.0.1 with libiodbc 3.52.5 and wxWidgets.

psqlodbcs config params are:
../configure --enable-pthreads --enable-unicode --with-iodbc CFLAGS="-ggdb -O0

The problem occured is that for varchar colums an insert is possible up to the max length, but an update only up to the count of characters of the value wich was last read.
F. E. a colum containg "12345" can't be updated to "12345aaa". It's always cut to "12345".

I found that ResolveOneParam(...) sets "used" to the number of last readed chars, instead of SQL_NTS (in fact "-3"). So on update only this number of chars is converted.

At the end of copy_and_convert_field I Found this statement:
if (pcbValue)
*((SQLLEN *) pcbValueBindRow) = len;
During the first read *pcbValue is "-3" for SQL_NTS columns, but the assignment sets it to the count of chars read.
I changed it to
if (pcbValue)
if (*pcbValue >= 0)
*((SQLLEN *) pcbValueBindRow) = len;
so SQL_NTS is retained in *pcbValue.

Now update works

Regards,
Thomas


------------------------------------------------------------ ----------

>Comment By: Hiroshi Inoue (hinoue)
Date: 2007-04-16 04:04

Message:
Could you tell me the ODBC API sequences in your app ?

regards,
Hiroshi Inoue

------------------------------------------------------------ ----------

You can respond by visiting:
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=10031 03&group_id=1000125

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org