Skip site navigation (1) Skip section navigation (2)

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

From: <noreply(at)pgfoundry(dot)org>
To: noreply(at)pgfoundry(dot)org
Subject: [ psqlodbc-Bugs-1003103 ] copy_and_convert_field(...) destroys bind info for wide char varchar columns
Date: 2007-04-18 10:24:29
Message-ID: 20070418102429.0FF6C217403@pgfoundry.org (view raw or flat)
Thread:
Lists: pgsql-odbc
Bugs item #1003103, was opened at 2007-04-15 16:39
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1003103&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: Thomas Zehbe (thomasz)
Date: 2007-04-18 12:24

Message:
Sorry for racting late. But I didn't get an email notifier.
Seems that I have to take a look.

I'n not sure what you mean with ODBC API sequences. So let
me give a first try. I attach a file with an code example.

The lines which provide the buffer on a per column base look
like that:
    SetColDefs (idx++, wxT("prodbezeichnung"),
DB_DATA_TYPE_VARCHAR, b.prodbezeichnung, SQL_C_WXCHAR,
                sizeof(b.prodbezeichnung),FALSE,TRUE);

It is the wxWidget interface defined as
wxDbTable::SetColDefs(). I provide only a single buffer for
every column. I believe that wxWidgets handles the param
buffers. It must be the case when I use a where clause typed
as a string. 

In wxDbTable::Open() wxWidgets first (indirectly) calls
PGAPI_BindParameter for every column wich should be read and
afterwords for every column wich should be updatable.

In my apps typically all coulumns are readable, but not all
are updatebale (primary key and all columns in a view wich
don't belong to the 'main' tabkle are not updatetable.

Hope this gives a first hint what happens.

Thanks and regards
Thomas





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

Comment By: Hiroshi Inoue (hinoue)
Date: 2007-04-17 01:43

Message:
Hmm don't use the same buffers for both columns and
 parameters ? If so, please treat them carefully.

regards,
Hiroshi Inoue

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

Comment By: Hiroshi Inoue (hinoue)
Date: 2007-04-16 06: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=1003103&group_id=1000125

pgsql-odbc by date

Next:From: noreplyDate: 2007-04-18 10:29:02
Subject: [ psqlodbc-Bugs-1000719 ] string representation for large objects ist wrong
Previous:From: ramondDate: 2007-04-17 08:26:11
Subject: Re: Unix domain socket

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group