Re: Postgres odbc driver bug

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Keith Millard <Kmillard(at)pumatech(dot)com>
Cc: "'pgsql-interfaces(at)postgresql(dot)org'" <pgsql-interfaces(at)postgresql(dot)org>, PostgreSQL odbc list <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Postgres odbc driver bug
Date: 2001-05-08 20:05:27
Message-ID: 200105082005.f48K5Rt27279@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces pgsql-odbc


OK, I have found another person who reported this problem. I have
attached their patch. Can you compare yours to theirs and let me know
what you think? Thanks.

> We have found a reproducible problem with the Postgres ODBC driver. It has
> to do with the parameter replacement feature in the driver. Below is a
> piece of test code that shows the problem. We were able to fix the problem
> by making a change to execute.c in the ODBC driver code (attached).
>
> odbc driver version : Found in both 6.50 and 7.01.0004.
> postgresql database version : Found with both 7.0.2 and 7.0.3 versions of
> Postgres.
> Server Operating System: Windows2000
> Client Operation System: Windows2000
>
> Explanation of the odbc driver bug:
>
>
> /*****************************************
> * ERROR HAPPENS HERE:
> * If we set the buffer that we binded to column "text1" now, it will
> FAIL.
> * The SQLExecute in doQuery() will succeed (finding 0 rows), and the
> * SQLFetchScroll call will return SQL_NO_DATA_FOUND.
> *
> * This is because of a bug in the odbc driver. The call to
> SQLNumResultCols
> * will execute the query in the driver, but the buffer that is binded is
>
> * empty, so no rows will be found. This of course assumes that the
> table
> * doesn't contain any empty records for the "text1" column, which is
> correct
> * for our test. Then when we call SQLExcute, the driver will realize it
> has
> * already done the query work and will not do it again, even though our
> * buffer for parameter substitution has changed (next line of code below
>
> * this comment).
> *****************************************/
>
> Zip file is attached. The code is currently set up to fail, but I describe
> in my comments that you can uncomment the code that sets the buffer before
> SQLNumResultCols to make things will work.
>
> Thanks for your attention,
> Keith Millard
>
>
> _____
>
> <http://www.swifttouch.com/SwiftCardJump.asp?SwiftLink=95NN9NB1Q1FWA> Alex
> Shore..
> Senior Software Engineer..
> Pumatech..
> tel 603-888-0666 x1017..
> ..
> ashore(at)pumatech(dot)com(dot)(dot)
> www.pumatech.com..
>
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Attachment Content-Type Size
unknown_filename text/plain 12.8 KB

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Scott Muir 2001-05-08 23:51:02 PGAccess in ver 7.1x
Previous Message Bruce Momjian 2001-05-08 17:29:52 Re: [JDBC] Re: Trouble with JDBC2 ResultSet.getDate()

Browse pgsql-odbc by date

  From Date Subject
Next Message Cedar Cox 2001-05-08 22:07:31 Re: encrypt odbc transactions?
Previous Message Bruce Momjian 2001-05-08 16:55:46 Re: [INTERFACES] Postgres odbc driver bug