Get Example source ABAP code based on a different SAP table
ID COMMIT-WORK • COMMIT WORK ABAP Statement • AND WAIT COMMIT WORK
COMMIT WORK> Short Reference >
ABAP_SYNTAX COMMIT WORK $[AND WAIT$].>
What does it do? The statement COMMIT WORK> closes the current SAP LUW> and opens a new one. BEGIN_SECTION VERSION 5 OUT All change requests from the current SAP LUW are committed. To do this, COMMIT WORK> performs the following actions: It executes all subroutines registered using PERFORM ON COMMIT>> in the current work process. The order is based on the order of registration or according to the priority specified using the addition LEVEL>. The following statements are not allowed to be executed in a subroutine of this type: PERFORM ... ON COMMIT$|ROLLBACK>> COMMIT WORK> ROLLBACK WORK>> The statement CALL FUNCTION ... IN UPDATE TASK>> can be executed. It raises an internal event for the persistence service of the Object Services>. If event handlers are registered by the persistence service, they collect the changes to the objects managed by the service and use CALL FUNCTION ... IN UPDATE TASK> > and pass them to a special update function module, registered as the final update module. It triggers the processing of all update function modules registered using CALL FUNCTION ... IN UPDATE TASK >> in the update work process or, for local updates>, in the current work process as well. All high-priority (VB1>) update function modules are executed in the order of their registration and in a shared database LUW>. If the addition AND WAIT> is not specified, the program does not wait in non-local updates until the update work process has executed it (asynchronous updates), and is resumed immediately after COMMIT WORK> instead. However, if the addition AND WAIT> is specified, program processing after COMMIT WORK> will not continue until the update work process has executed the high-priority update function modules (synchronous updating). When all high-priority update function modules are completed successfully, the statement executes the low-priority (VB2>) update function modules in the order of registration in a shared database LUW in the update work process. No database commits> and no database rollbacks> can occur, and the update control cannot be modified in the processing of an update function module triggered using COMMIT WORK> is being processed. Any statements that would produce this situation are forbidden statements in updates> and always produce runtime errors. As before, no authorization checks> can be made. After the execution of high-priority update function modules, the function modules registered using CALL FUNCTION ... IN BACKGROUND UNIT>> and CALL FUNCTION ... IN BACKGROUND TASK>> (obsolete) are themselves executed in a single database LUW per RFC destination>. It handles all SAP locks> set in the current program in accordance with the value of the formal parameter _SCOPE > of the corresponding lock function modules. It triggers a database commit> on all currently open database connections >, which also terminates the current database LUW> and closes all database cursors>. Furthermore, the COMMIT WORK> raises the event TRANSACTION_FINISHED > from the system class CL_SYSTEM_TRANSACTION_STATE>>, where the parameter KIND> has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK>. The time when this event is raised is described in the documentation for the event in the class:
In synchronous updates>, local updates>, and outside updates, TRANSACTION_FINISHED> is raised by COMMIT WORK> once processing is finished.
In asynchronous updates>, TRANSACTION_FINISHED> is raised by the statement COMMIT WORK > when the update is initiated. Resources for preparation work can be cleaned up in the event handlers for this event before the update is performed. However, this is no guarantee that the update has not already been performed. If the statement COMMIT WORK> is executed in programs called in a special way, the following special features apply:
In a program executed using batch input> or if the program was called using the statement CALL TRANSACTION USING>>, COMMIT WORK> terminates batch input processing by default. This setting can be overwritten in the statement CALL TRANSACTION USING > by using the component RACOMMIT> of the structure CTU_PARAMS>>, passed to the statement OPTIONS FROM>.
In a program called using CALL DIALOG>> , COMMIT WORK> does not trigger the processing of subroutines or function modules registered using PERFORM ON COMMIT>> and CALL FUNCTION ... IN UPDATE TASK>> and hence does not close the current SAP LUW. At the earliest, the SAP LUW can be closed by the statement COMMIT WORK> in the calling program. Only those background remote function calls> or obsolete transactional remote function calls > registered using CALL FUNCTION ... IN BACKGROUND UNIT>> or CALL FUNCTION ... IN BACKGROUND TASK>> (obsolete) within a dialog module> are actually started here using COMMIT WORK>. Any bgRFCs >, tRFCs>, or qRFCs> registered in a dialog module and not started there using COMMIT WORK> are not executed.
The statement COMMIT WORK> must not be executed in updates or in the execution of subroutines registered using PERFORM ... ON ${COMMIT$|ROLLBACK$}>.
The statement COMMIT WORK> must not be executed in units or LUWs that are managed by background RFC calls (bgRFC> and the (obsolete) tRFC>, qRFC>). System Fields> sy-subrc>>Meaning> 0The addition AND WAIT> was specified, and the update of the update function modules was successful. 4The addition AND WAIT> was specified, and the update of the update function modules was not successful. The statement COMMIT WORK> always sets sy-subrc> to 0 if the addition AND WAIT> is not specified. END_SECTION VERSION 5 OUT
Latest notes:
An SAP LUW not closed by COMMIT WORK> but by ending the current program or closing the ABAP_ISESS > is ignored by the registered procedures. Registered update function modules remain on the database but can no longer be executed.
COMMIT WORK> empties global temporary tables> of all currently open database connections> and prevents the runtime error COMMIT_GTT_ERROR> in the case of implicit database commits>. BEGIN_SECTION SAP_INTERNAL_HINT During the processing of events that were triggered during COMMIT WORK>, the internal system field sy-oncom> has the value E >. Instead of sy-oncom> the system class CL_SYSTEM_TRANSACTION_STATE> should be used in programs. END_SECTION SAP_INTERNAL_HINT
The statement COMMIT WORK> closes all database cursors>. AB-SQL statements that access a database cursor later (SELECT>> loop) raise a uncatchable exception. NON_V5_HINTS