qres->status = PQresultStatus(pgres);
In the bad primary key case, this returns PGRES_FATAL_ERROR.
Then, in SC_execute():
/* Check the status of the result */
was_ok = QR_command_successful(res);
was_nonfatal = QR_command_nonfatal(res);
was_fatal = QR_command_fatal(res);
else if (was_fatal)
And STMT_BAD_ERROR is what returns 08S01 when I call SQLGetDiagRec.
I could really use some help with this...
From: Dave Page [mailto:dpage(at)vale-housing(dot)co(dot)uk]
Sent: Wed 9/7/2005 9:02 AM
To: Scot Loach; Anoop Kumar
Subject: RE: [ODBC] changed behavior in libpq odbc driver
> -----Original Message-----
> From: Scot Loach [mailto:sloach(at)sandvine(dot)com]
> Sent: 07 September 2005 13:48
> To: Dave Page; Anoop Kumar
> Cc: pgsql-odbc(at)postgresql(dot)org
> Subject: RE: [ODBC] changed behavior in libpq odbc driver
> so I'm definitely still able to reproduce this problem.
> The test I'm running is somewhat complex, I can work on
> simplifying it.
> Maybe the error code is left around from before and not
> properly cleared?
Well the only time the error code should be set is if libpq reports the
connection as being bad, so if you're definitely seeing it, it must be
coming from somewhere else, or you're not checking the error code when
it actually arrives.
Can you add a mylog line into the relevant part of the fix I posted so
youo can see if the error code is being set somewhen that you don't
pgsql-odbc by date
|Next:||From: Dave Page||Date: 2005-09-16 07:51:07|
|Subject: Re: ODBC Driver on Windows 64 bit|
|Previous:||From: Robin Weber||Date: 2005-09-15 17:53:23|
|Subject: Re: ODBC Driver Failure- MS Access- Large record volume|