Transaction control with DBTools 3.1

Article ID: 832
Last updated: 02 Feb, 2008
Article ID: 832
Last updated: 02 Feb, 2008
Revision: 1
Views: 3116
Posted: 16 Nov, 1998
by Dean J.
Updated: 02 Feb, 2008
by Dean J.

New transaction control protocol for DBTools version 3.1.


Transaction control has a new protocol for DBTools 3.1. The new transaction processing system is cleaner, more intuitive, is consistent across databases, and supports nested transactions and savepoints on databases that support this.

Supported features include:

  • Non-transaction login databases are supported (INFORMIX)
  • Nested transactions are supported (SYBASE, MS SQL SERVER)
  • Savepoints are supported (SYBASE, ORACLE, MS SQL SERVER)
  • Named transactions are supported (SYBASE, MS SQL SERVER)
  • Non-supported features on a particular database will be ignored (i.e. code is portable).

There are no longer any commands that implicitly starts a transaction (e.g. writable cursors). It is up to the user to explicitly call the transaction control commands (beginTransaction(), rollbackTransaction(), commitTransaction()).


Examples of what the new open transaction model looks like:

  • Connections are always created auto-committed.
  • Connection::beginTransaction() begins transaction.
  • Connection::rollbackTranction(savepoint) rolls back to save point.
  • Connection::rollbackTranction() rolls back to begin transaction and ends transaction control.
  • Connection::commitTransaction() commits paired transaction. An optional savepoint argument is available. If the database does not support nested transactions, the outer transaction is committed.

For those familiar with previous transaction control functionality:

DBTools autoCommit function has been obsolesced which means DBTools internal API will not rely on it. User?s autoCommit setting will not affect transaction control.

Backward compatibility (for those who have applications using DBTools 3.0.2, or earlier, transaction control protocol):

  • Applications which use the old transaction protocol will compile, but might not act in the same manner.
  • Applications which use transactions with beginTransaction() will act properly.
  • Applications which use transactions without beginTransaction() will not act properly.
Code changes are needed:
  • Replacing autoCommit(FALSE) with beginTransaction() will suffice for most programs.
  • Applications which use cursor for update on ORACLE or INFORMIX will not act properly. You will have to change your code to not rely on an implicit transaction being started. Nesting your cursor control code inside cn.beginTransaction() and cn.commitTransaction() will emulate the old behavior. Note: If you don't nest your writable cursor code inside a transaction your program will likely encounter serious problems.
  • Nested transactions will now work, i.e. there are no transactions going on in the background.
  • Named transactions and savepoint features have been introduced.
This article was:   Helpful | Not helpful
Report an issue
Article ID: 832
Last updated: 02 Feb, 2008
Revision: 1
Views: 3116
Posted: 16 Nov, 1998 by Dean J.
Updated: 02 Feb, 2008 by Dean J.

Others in this category