Hello.
I have been thinking about savepoints.
What do you think about the following:
Create transaction.h and transaction.c.
They would keep the knoledge about the following things:
- Current transaction state (is in autocommit mode, in transaction,
and the savepoint stack structure.
- Each transaction stack point would maintain a list of open cursors.
The stack would contain the following things:
- At the bottom of the stack is the autocommit mode (tr[0]).
- tr[1] contains the transaction's BEGIN block state.
- tr[2] contains the information about the first savepoint.
This would make the savepoint rollback work with cursors:
ODBC side manages the open cursors during savepoint rollback.
Rolling back a savepoint destroys that savepoint's and the later savepoint's
cursors. ODBC must not try to close the cursor after rollback,
or a database error occurs.
What do you think? Is this transaction state tracking necessary in the
ODBC side? Or does or will the database backend handle this some day
some way?
Marko Ristola