Received: from p2272.nsk.ne.jp (p2272.nsk.ne.jp [210.145.18.145]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f453hWA60997 for ; Fri, 4 May 2001 23:43:32 -0400 (EDT) (envelope-from Inoue@tpf.co.jp) Received: from mcadnote1 (ppm154.noc.fukui.nsk.ne.jp [210.161.188.73]) by p2272.nsk.ne.jp (8.9.3/3.7W-20000722) with SMTP id MAA21946; Sat, 5 May 2001 12:43:19 +0900 (JST) From: "Hiroshi Inoue" To: "Keith Millard" Cc: Subject: RE: Postgres odbc driver bug Date: Sat, 5 May 2001 12:43:41 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01C0D561.03D3F3A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-Archive-Number: 200105/24 X-Sequence-Number: 1550 This is a multi-part message in MIME format. ------=_NextPart_000_010B_01C0D561.03D3F3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please try the latest driver 7.01.0005. It solves several parameter handling problems. regards, Hiroshi Inoue -----Original Message----- From: pgsql-interfaces-owner@postgresql.org [mailto:pgsql-interfaces-owner@postgresql.org]On Behalf Of Keith Millard Sent: Tuesday, May 01, 2001 10:37 PM To: 'pgsql-interfaces@postgresql.org' Subject: [INTERFACES] Postgres odbc driver bug 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 ------=_NextPart_000_010B_01C0D561.03D3F3A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please try the latest driver=20 7.01.0005.

It solves several parameter handling=20 problems.

regards,

Hiroshi Inoue

-----Original Message-----
From:=20 pgsql-interfaces-owner@postgresql.org=20 [mailto:pgsql-interfaces-owner@postgresql.org]On Behalf Of Keith= =20 Millard
Sent: Tuesday, May 01, 2001 10:37 PM
To:=20 'pgsql-interfaces@postgresql.org'
Subject: [INTERFACES] Postgre= s=20 odbc driver bug

We=20 have found a reproducible problem with the Postgres ODBC driver. It has to do with the parameter= =20 replacement feature in the driver. = ;=20 Below is a piece of test code that shows the problem. We were able to fix the problem= by=20 making a change to execute.c in the ODBC driver code=20 (attached).

=

odbc=20 driver version : Found in both 6.50 and=20 7.01.0004.

postgresql=20 database version : Found with both 7.0.2 and 7.0.3 versions of=20 Postgres.

Server=20 Operating System: Windows2000

Client=20 Operation System: Windows2000

=

Explanation of= the=20 odbc driver bug:

  = =20 /*****************************************
    * ERROR= =20 HAPPENS HERE:
    * If we set the buffer that we binded= to=20 column "text1" now, it will FAIL.
    * The SQLExecute = in=20 doQuery() will succeed (finding 0 rows), and the
    *= =20 SQLFetchScroll call will return SQL_NO_DATA_FOUND.
   = =20 *
    * This is because of a bug in the odbc driver. Th= e=20 call to SQLNumResultCols
    * will execute the query i= n the=20 driver, but the buffer that is binded is
    * empty, = so no=20 rows will be found. This of course assumes that the=20 table
    * doesn't contain any empty records for the= =20 "text1" column, which is correct
    * for our test.&nb= sp;=20 Then when we call SQLExcute, the driver will realize it=20 has
    * already done the query work and will not do i= t=20 again, even though our
    * buffer for parameter=20 substitution has changed (next line of code below
    = *=20 this comment).
   =20 *****************************************/

Zip file is=20 attached. The code is currently set up to fail, but I describe in m= y=20 comments that you can uncomment the code that sets the buffer before=20 SQLNumResultCols to make things will work.

=

Thanks=20 for your attention,

Keith=20 Millard

------=_NextPart_000_010B_01C0D561.03D3F3A0--