ABAP - Keyword Documentation →  ABAP - Programming Language →  Processing External Data →  ABAP Database Access →  Data Consistency →  Database LUW → 

Database Commit

In AS ABAP, database commits are triggered either implicitly or explicitly.

Hint

A database commit closes all opened database cursors. In particular, in SELECT loops and after the statement OPEN CURSOR, database commits should not be triggered by mistake in one of the ways listed here.

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 program waits for a user action and does not occupy a work process during this time. The next free work process is assigned to the program in the next dialog step.
The current work process passes control to a different work process or system. An exception to this are updates. During update processing, sRFC and aRFC do not cause work processes to be switched or database commits to be executed.
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.
To receive data from another AS instance, 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.
A database commit is executed while the methods START_MESSAGE_DELIVERY and STOP_MESSAGE_DELIVERY of a consumer object are being executed.
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.
After the interruption, the program is allocated the next free work process. An exception to this are updates.
These messages interrupt the current dialog step (see above).

The implicit database commit takes place on all currently open database connections of the current work process. The situations above cause a work process to be switched while a program is running, but it is also possible for entire programs to be executed in a different work process, such as when a program is called in a background work process in background processing. Here, a database commit is also made when the work process is switched.

Hints

Explicit Database Commits

Database commits can be triggered explicitly in ABAP programs in the following ways:

COMMIT statements are not allowed in AMDP methods.

Hints

Database Commit on Secondary Connections

Implicit deactivations of a secondary connection or a service connection at the end of an internal session trigger a database commit in the transaction context of this database connection. For more information, see Database Connections.

If the internal session is switched on the standard connection, there is no database commit and no database rollback.