firebird-odbc-devel

[Firebird-odbc-devel] SQLColumns() and transaction

[Dimitry S. <sd...@ib...>]

   Hello, All.

   Should call of SQLColumns() start transaction?

   I wonder because now with auto-commit mode off, this call _does_ start transaction and 
following call of SQLDisconnect() without SQLEndTran() return 25000 error code.
   It is not clear for me from ODBC docs whether SQLColumns() is "an SQL statement that 
can be contained within a transaction" or not.

-- 
   WBR, SD.

Re: [Firebird-odbc-devel] SQLColumns() and transaction

[Alexander P. <ale...@gm...>]

Hi Dimitry,

SQLColumns() gets data from system tables and it starts transaction of 
course and therefore If auto-commit mode off, driver considers that this 
transaction remains active.

On 08.10.2013 1:04, Dimitry Sibiryakov wrote:
>     Should call of SQLColumns() start transaction?
>
>     I wonder because now with auto-commit mode off, this call_does_  start transaction and
> following call of SQLDisconnect() without SQLEndTran() return 25000 error code.
>     It is not clear for me from ODBC docs whether SQLColumns() is "an SQL statement that
> can be contained within a transaction" or not.

Re: [Firebird-odbc-devel] SQLColumns() and transaction

[Dimitry S. <sd...@ib...>]

08.10.2013 9:21, Alexander Potapchenko wrote:
> SQLColumns() gets data from system tables and it starts transaction of
> course and therefore If auto-commit mode off, driver considers that this
> transaction remains active.

   But the question is whether it should start connection-wide transaction or a local one.

-- 
   WBR, SD.

Re: [Firebird-odbc-devel] SQLColumns() and transaction

[Alexander P. <ale...@gm...>]

I think such functions should start local transactions, but in current 
implementation that's not so.
You can add this issue into the bug tracker.

On 08.10.2013 12:24, Dimitry Sibiryakov wrote:
> 08.10.2013 9:21, Alexander Potapchenko wrote:
>> SQLColumns() gets data from system tables and it starts transaction of
>> course and therefore If auto-commit mode off, driver considers that this
>> transaction remains active.
>     But the question is whether it should start connection-wide transaction or a local one.
>