Home How To Online Documentation Support Download Order

 

 

Connecting to databases
Transactions
Executing an SQL command
Executing stored procedures
Binding input parameters
Fetching result set
Fetching multiple result sets
Optimizing Database Performance
Returning output parameters
Working with Long or Lob(CLob, BLob) Data
Working with date/time values
Error handling
Using native API
Query examples


Transactions

A transaction is a unit of work that is done as a single operation. There are two base characteristics of transaction:

Transaction mode

Transactions can be completed by either being committed or being rolled back. When a transaction is committed, the changes made in that transaction are made permanent. When a transaction is rolled back, the affected rows are returned to the state they were in before the transaction was started.

Transactions can be in one of two modes: auto-commit mode or manual-commit mode.

In auto-commit mode, every database operation is a transaction that is committed when performed. In databases without transaction support, auto-commit mode is the only supported mode. In such databases, statements are committed when they are executed and there is no way to roll them back; they are therefore always in auto-commit mode.

In manual-commit mode, applications must explicitly complete transactions by calling SAConnection::Commit to commit them or SAConnection::Rollback to roll them back. This is the normal transaction mode for most relational databases.

Note: The default transaction settings are DBMS-defined.

Using SQLAPI++ to set auto-commit mode compulsory you should call SAConnection::setAutoCommit method with parameter value SA_AutoCommitOn. To set manual-commit mode you should call SAConnection::setAutoCommit method with parameter value SA_AutoCommitOff. If you didn't set transaction mode explicitly then the Library uses the default DBMS transaction settings. See DBMS documentation to get information concerning the default transaction mode.

If you disconnected from server without commit, then the result of transaction depends on underlying DBMS. It can either being committed or being rolled back. See DBMS documentation.

Calling SAConnection::Commit or SAConnection::Rollback in auto-commit is safe (it has no effect). If you are working in manual-commit mode and call SAConnection::Commit method then current transaction is committed and new one is started. If you are working in manual-commit mode and call SAConnection::Rollback method then current transaction is rolled back and new one is started.

Transaction Isolation Level

Transaction isolation refers to the degree of interaction between multiple concurrent transactions. SQL-92 defines four isolation levels, all of which are supported by SQLAPI++:

  • Read uncommitted (the lowest level where transactions are isolated just enough to ensure that physically corrupt data is not read)
  • Read committed
  • Repeatable read
  • Serializable (the highest level, where transactions are completely isolated from one another)

SQLAPI++ maps different isolation levels on underlying DBMS. You can set transaction isolation level explicitly by calling SAConnection::setIsolationLevel .

If you didn't set transaction isolation level explicitly then the Library uses the default DBMS transaction settings. See DBMS documentation to get information concerning the default transaction isolation level.

Note that if you change isolation level it causes implicit commit for this connection.

Problems and Questions

If you haven't found the answer to your questions or have some problems on using the Library, please, send e-mail to howto@sqlapi.com.