Re: [INTERFACES] 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: PostgreSQL odbc list <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: [INTERFACES] Postgres odbc driver bug
Date: 2001-05-08 16:55:46
Message-ID: 200105081655.f48GtkL12980@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces pgsql-odbc


OK, I have created a context diff of your changes, which is attached.
Can someone comment on this? The patch appears to deal with
STMT_PREMATURE differently than our current code.

In fact, it seems to disable this code:

/*
* If the statement is premature, it means we already executed it from
* an SQLPrepare/SQLDescribeCol type of scenario. So just return
* success.
*/
if (stmt->prepare && stmt->status == STMT_PREMATURE)

> 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 2.1 KB

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Bruce Momjian 2001-05-08 17:29:52 Re: [JDBC] Re: Trouble with JDBC2 ResultSet.getDate()
Previous Message Bruce Momjian 2001-05-08 16:44:24 Re: [JDBC] Re: Trouble with JDBC2 ResultSet.getDate()

Browse pgsql-odbc by date

  From Date Subject
Next Message Bruce Momjian 2001-05-08 20:05:27 Re: Postgres odbc driver bug
Previous Message Dave Page 2001-05-08 16:11:37 RE: ADO support