Re: Most recent driver aborts transaction after one error

Hiroshi Inoue wrote:
> Bart Samwel wrote:
>> Hi there,
>>
>> I have just upgraded to PostgreSQL 8.1 and I have encountered the
>> following problem. When I connect through psqlODBC 8.01.0200 (PostgreSQL
>> Unicode), a sequence like the following:
>>
>>    <start a transaction>
>>    DROP SEQUENCE BAZ;
>>    SELECT 1;
>>
>> will give an error on the DROP SEQUENCE:
>>
>>    "42P01: Error while executing the query;
>>    ERROR:  sequence "app_bod_seq" does not exist"
>>
>> and will then give an error on the SELECT 1:
>>
>>    "25P02: Error while executing the query;
>>    ERROR:  current transaction is aborted, commands ignored until end of
>>    transaction block"
>>
>> When connecting through the psqlODBC 8.00.0102, I do *not* get the
>> second error. This is, in fact, what I would expect. It is also what
>> pretty much all other databases do (our application also runs on
>> Informix, Firebird, Oracle and MS SQL Server, and they all allow failed
>> commands in transactions without forcing a rollback). And it is what the
>> 8.00.0102 driver did (or appeared to do?). Was this behaviour changed
>> on purpose, and if so, why? And is there a way to work around it? ;-)
>
> Please try Experimental Enhanced Branch(psqlODBC 07.03.0260) at
>   http://pgfoundry.org/projects/psqlodbc/ .
> You can specify the *Level of rollback on errors* option as *Statement*
> using the version.

After working around some problems, my test situation worked perfectly.
Thanks for the hint!

These were the problems I encountered:

1. SQLGetInfo(SQL_DBMS_NAME) returns "PostgreSQL35W", and
SQLGetInfo(SQL_DBMS_VER) returns a number in the 07.30 range, while I'm
running PostgreSQL 8.1. I think that "PostgreSQL35W" is fine for a
SQL_DRIVER_NAME, but SQL_DBMS_NAME should be simply "PostgreSQL", and
SQL_DBMS_VER should return the DBMS version, not the driver version
(which should be returned by SQL_DRIVER_VER).

2. I also encountered an access violation while exiting. The call stack
was not very informative:

      ntdll.dll!_RtlpWaitForCriticalSection@4()  + 0x5b
      ntdll.dll!_RtlEnterCriticalSection@4()  + 0x46
    psqlodbc35w.dll!023a097e()
      ntdll.dll!_RtlpFreeDebugInfo@4()  + 0x57
      ntdll.dll!_RtlDeleteCriticalSection@4()  + 0x78

If you want me to try this with a debug-compiled psqlodbc35w, just say
the word!

Cheers,
Bart