A database commit closes all opened
database cursors. It is particularly important that database commits are not triggered (in one of
the ways listed here) in SELECT
loops and after the statement OPEN CURSOR.
Implicit Database Commits
The implicit database commits in an AS ABAP are caused by the fact that an
AS ABAP uses its own
work processes to connect to the database system. A work process can only ever execute a single
database LUW but cannot
interfere with the database LUWs belonging to other work processes. Since an ABAP program can be executed
by different work processes during its runtime, the database LUW for the current work process must be
completed each time an action takes place that leads to a change of work process. As a result, a database commit is performed implicitly in the following situation:
The current work process passes control to a different work process or system. An exception to this are
updates. When updates are running,
aRFC do not cause work processes to be switched or database commits to be executed.
Completion of a function module called in a separate work process using a synchronous remote function call.
Usually, a new work process is allocated to the call program. If a new
sRFC follows quickly enough, and
enough free work processes exist, the work process sRFC continues to be used, but an implicit database commit is performed regardless.
Execution of the statement RECEIVE in a callback routine specified in an asynchronous RFC
To receive data from the other application server, the current work process must be interrupted before the callback routine is executed A database commit is performed, except during the update.
A database commit is executed before each response is sent in an ICF server program or ICF client
program. An exception to this are updates. This behavior applies regardless of whether the communication is stateless or stateful.
Each time a message is sent and each time APC processing is exited, a database commit is executed. An exception to this are
updates. More specifically,
the methods BIND_AMC_MESSAGE_CONSUMER and UNBIND_AMC_MESSAGE_CONSUMER (for binding an ABAP messaging channel) produce a database commit.
If (in the case of implicit database commits) a global
temporary table filled using Open SQL statements is not emptied by an explicit database commit or
database rollback or by the statement DELETE FROM without WHERE condition, the runtime error COMMIT_GTT_ERROR occurs.
Explicit Database Commits
Database commits can be triggered explicitly in ABAP programs in the following ways:
The relevant database-specific Native SQL statement is used.
In ADBC, only the method
COMMIT of the class
CL_SQL_CONNECTION can be used to do this. In other
cases, the database interface does not detect the end of the transaction and might not be able to perform certain actions.
Any COMMIT statement embedded statically between EXEC and ENDEXEC is detected by the database interface and any required actions performed.
Calling the function module DB_COMMIT. This function module encapsulates the corresponding Native SQL statement. By default, the database commit is triggered on the
connection currently open for EXEC SQL. The commit is triggered explicitly on the standard connection
by passing the value of abap_true to the input parameter IV_DEFAULT. The
function module DB_COMMIT raises the event DB_TRANSACTION_FINISHED of the class CL_DBI_TRANSACTION_STATE, which is handled by the application log framework.
A simple database commit in an ABAP program is generally done using the statement COMMIT CONNECTION (the standard connection can be specified here using
default). The database LUW can be monitored by the application
log by using the function module DB_COMMIT. Apart from the database
commit itself, using the statement COMMIT WORK also has certain other consequences with respect to the
All the methods specified here for explicit database commits empty
global temporary tables and prevent the runtime error COMMIT_GTT_ERROR in the case of implicit database commits.