The following guidelines apply when using
transactions in an application. Be sure to follow them to have
optimal performance for your scripts that use transactions.
Transactions can’t be nested. Once a
transaction is started, you can’t start another until the current
transaction has been committed or rolled back. Use the Tools_GetTranLevel()
function to find out whether a transaction is currently
active.
Keep transactions as short as possible.
Don’t include operations that aren’t an essential part of the
transaction. For example, don’t update user-interface elements
within a transaction. This isn’t essential to the transaction and
should be done after the transaction is complete.
If a transaction contains many table
operations, try to restructure the transaction into several smaller
transactions.
Don’t allow user interaction while a
transaction is in progress. For example, a user may allow a dialog
to remain open for an extended period of time, effectively blocking
other users from accessing the records being accessed by the
transaction.
To minimize the possibility of deadlocks,
access the tables in each of your transactions in a consistent
order. For example, assume a transaction accesses a record in table
A and then a record in table B. The other transactions in your
application should that access these tables should use the same
order. A transaction that didn’t follow this guideline and accesses
a record in table B and then one in table A will increase the
chance of a deadlock occurring.
If you use the call sproc statement within a transaction,
the operations performed by the stored procedure are considered
part of the transaction. If a transaction is active, and the stored
procedure called attempts to start another transaction, an
exception will be thrown indicating the transaction level
changed.
Tables created or dropped during the
transaction won’t be considered part of the transaction.
Temporary tables accessed during the
transaction won’t be considered part of the transaction.
Table operations performed in scripts that
aren’t run immediately, such as those started by call background and run script delayed, won’t be included in the
transaction.
Any pass-through sanScript executed during
the transaction won’t be considered part of the transaction.