1/19/2016 9:48:13 AM

Before getting into Implicit or Explicit commits we need to understand the LUW. There are two types of LUW(Database LUW and SAP LUW)

Database LUW 

A database LUW is a non-separable sequence of database operations that ends in a database commit. The database LUW is either executed completely by the database system, or not at all. After a database LUW has been successfully completed, the database returns to a consistent status and a new database LUW is opened. If an error is discovered within a database LUW, all database changes made since the start of the database LUW can be canceled using a database rollback. The database is subsequently restored to the same status as before the start of the database LUW. 


A database commit closes all opened database cursors. In Open SQL, this particularly affects SELECT loops and the statement OPEN CURSOR. 


Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked to an implicit database commit, an application program is not automatically linked to a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step. 

To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW. Instead, they are first registered and then executed by a single work process, that is, in a single database LUW. 

Two techniques are available for bundling the change statements in a database LUW: 

Bundling via function modules (update) 

Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process. (synchronous and asynchronous update) or in the current work process (local update). 

Bundling via function modules (transactional RFC) 

Through the statement CALL FUNCTION... IN BACKGROUND TASK|UNIT, a remote-enabled function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ). 

Bundling via subprograms 

Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process. 

Statements for SAP LUWs 

A SAP LUW is controlled via the Open SQL statements 





A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an ABAP system, while the transactional RFC creates LUWs in distributed systems.

Database commits are triggered either implicitly or explicitly in an ABAP system. 

Implicit Database Commits 

The implicit database commits in an ABAP system are caused by the fact that the SAP system is logged on to the database system via its work processes. 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: 

Completion of a dialog step 

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. 

Calling a function module in a synchronous or asynchronous Remote Function Call 

The current work process hands over control to a different work process or system. 

Completion of a function module accessed with a synchronous Remote Function Call in a separate work process 

The calling program is assigned a new work process. 

Execution of a RECEIVE statement in a callback routine specified in an asynchronous RFC 

The current work process is interrupted so that the data can be received from the other application server. 

Interruption of the current work process with a WAIT statement. 

After interruption, the program is assigned the next free work process. 

Sending error and information messages and warnings. 

These messages interrupt the current dialog step .

Explicit Database Commits 

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

Use of the corresponding database-specific native sql statement. 

Calling the function module DB_COMMIT. 

This function module, which has no parameters, encapsulates the corresponding native sql statement. 

Executing the open sql statement COMMIT WORK. 

If you like this blog, please share (Facebook/LinkedIn/Google+) to click below links so it will reach to others.