I've found a problem with this.
This causes the correct state to be returned on db disconnect, great.
Unfortunately 08S01 is now returned for other errors as well.
For example, trying to insert a row with a duplicate key into a table will cause 08S01 to be returned now, this was not
thebehavior before.
scot.
-----Original Message-----
From: Anoop Kumar [mailto:anoopk@pervasive-postgres.com]
Sent: Wed 8/31/2005 1:51 AM
To: Scot Loach
Cc: pgsql-odbc@postgresql.org; Dave Page
Subject: RE: [ODBC] changed behavior in libpq odbc driver
Hi All,
Please find the patch for the other bug pointed out by Scot. (Thanks to
Sivakumar)
"Another difference is the "state" that is returned from SQLGetDiagRec
when a connection is lost during a query. This used to return 08S01.
It now returns HY000."
I request you to review this patch as well.
Regards
Anoop
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-
> owner@postgresql.org] On Behalf Of Scot Loach
> Sent: Sunday, August 21, 2005 8:31 PM
> To: Marko Ristola
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] changed behavior in libpq odbc driver
>
> Thanks for the clarification, Marko.
> I use ODBC 3.0, so it would seem that this is a bug.
>
> scot.
>
>
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org]On Behalf Of Marko Ristola
> Sent: Sunday, August 21, 2005 10:36 AM
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] changed behavior in libpq odbc driver
>
>
>
> Please check, but ODBC 3 should return SQL_NO_DATA, when
> no data has been updated.
>
> ODBC 2 should return SQL_SUCCESS wether any rows were updated, or not.
>
> So it depends on the ODBC standard, that the client program chooses.
>
> Marko Ristola
>
> Scot Loach wrote:
>
> >I'm not sure whether the old driver or the new one is correct.
> >
> >When executing an UPDATE query with a WHERE clause, if the WHERE
clause
> does not match any rows, the old driver returns SQL_NO_DATA. The new
> driver returns SQL_SUCCESS.
> >
> >
> >
> >---------------------------(end of
broadcast)---------------------------
> >TIP 9: In versions below 8.0, the planner will ignore your desire to
> > choose an index scan if your joining column's datatypes do not
> > match
> >
> >
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster