Abort Policy for Transactions and Statements
Transactions and statements can be aborted by any of the following entities:
• An application
• The DBMS
Applications can abort transactions or statements as a result of the following conditions:
• ROLLBACK statement
• Timeout (if set)
The DBMS aborts statements and transactions as a result of the following conditions:
• Deadlock
• Transaction log full
• Lock quota exceeded
• Error while executing a database statement
How to Direct the DBMS to Roll Back an Entire Transaction or Statement
To direct the DBMS to roll back an entire transaction (or a single statement), use the SET SESSION WITH ON ERROR = ROLLBACK STATEMENT | TRANSACTION statement.
Note: The errors Deadlock, Transaction Log Full, and Lock Quota Exceeded always roll back the entire transaction regardless of the current ON_ERROR setting.
Effects of Aborted Transactions
When a statement or transaction is aborted (due to an application or the DBMS itself), the following occurs:
• Rolling back a single statement does not cause the DBMS to release any locks held by the transaction. Locks are released when the transaction ends.
• If cursors are open, the entire transaction is always aborted.
• When an entire transaction is aborted, all open cursors are closed, and all prepared statements are invalidated.
When writing embedded SQL applications, your application must include logic for handling operator interrupts. By default, if the application is aborted during a transaction, the transaction is rolled back. This also applies to Actian X tools. For example, if you abort Query-By-Forms (QBF) while it is performing an update, the update is rolled back.
Last modified date: 08/14/2024