There are issues to consider when using transactions in your applications.
A rollback statement, without a transaction or savepoint name, always rolls back statements to the outermost begin transaction (explicit or implicit) statement and cancels the transaction. If there is no current transaction when you issue rollback, the statement has no effect.
In triggers or stored procedures, rollback statements, without transaction or savepoint names, roll back all statements to the outermost begin transaction (explicit or implicit).
rollback does not produce any messages to the user. If warnings are needed, use raiserror or print statements.
Grouping a large number of Transact-SQL commands into one long-running transaction may affect recovery time. If SAP ASE fails during a long transaction, recovery time increases, since SAP ASE must first undo the entire transaction.
You can have as many databases in a user transaction as there are in your SAP ASE installation. For example, if your SAP ASE has 25 databases, you can include 25 databases in your user transactions.
You can independently execute a remote procedure call (RPC) from any transaction in which it is included. In a standard transaction (one that does not use Open Client DB-Library/C two-phase commit or SAP ASE distributed transaction management features), commands executed via an RPC by a remote server are not rolled back with rollback and do not depend on commit to be executed.
Transactions cannot span more than one connection between a client application and a server. For example, a DB-Library/C application cannot group SQL statements in a transaction across multiple open DBPROCESS connections.
SAP ASE performs two scans of the log: the first scan looks for data page deallocation and unreserved pages, the second scan looks for log page deallocation. These scans are an internal optimization, transparent to users, and are performed automatically; you cannot switch the scans on or off.
With post-commit optimization, SAP ASE remembers the “next” log page (in the backward direction) containing these log records. During the post-commit phase, SAP ASE moves to the “next” page requiring post-commit work after processing records from a page. In a concurrent environment, where many users log their transactions to syslogs at the same time, post-commit optimization can improve the performance of post commit operation by avoiding reads or scans of unnecessary log pages.
The optimization does not show up in any diagnostics.