SAP DB COMMIT Get Example source ABAP code based on a different SAP table
SAP Help
Database Commit In
AS ABAP>, database commits are triggered either implicitly or explicitly. ITOC Latest notes: NON_V5_HINTS 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. ABAP_HINT_END BEGIN_SECTION VERSION 5 OUT 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 log on 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 for every action that can lead 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 passes control to a different work process or system. An exception to this are updates>. During updates, sRFC> and 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 assigned to the calling 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. Use of the statement RECEIVE>> in a callback routine specified in an asynchronous RFC To receive data from another ABAP_ASINSTANCE , the current work process must be interrupted before the callback routine is executed. A database commit is performed, except during the update. HTTP/HTTPS/SMTP communication executed using the Internet Communication Framework> 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 is independent of whether the communication is stateless or stateful. Receiving messages from ABAP messaging channels> A database commit is executed while the methods START_MESSAGE_DELIVERY> and STOP_MESSAGE_DELIVERY> of a consumer object are executed. Execution of WebSocket or TCP communication using ABAP Push Channels 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. Current work process interrupted using the statement WAIT UP TO>>, WAIT FOR ASYNCHRONOUS TASKS>>, or WAIT FOR MESSAGING CHANNELS>>. After the interruption, the program is assigned the next free work process. An exception to this are updates. Sending error messages>, information messages>, and warnings>. 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. Latest notes: When an ABAP_ISESS > is exited, there is no implicit database commit on the standard connection> and no database rollback>. This must be programmed explicitly if required. If a global temporary table> filled using AB-SQL statements is not emptied by an explicit database commit or database rollback in the case of implicit database commits or by the statement DELETE FROM>> without WHERE > condition, the runtime error COMMIT_GTT_ERROR> occurs. NON_V5_HINTS ABAP_HINT_END 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. Executing the AB-SQL > statement COMMIT CONNECTION>>. The database commit takes place on the specified database connection>. 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. Executing the AB-SQL > statement COMMIT CONNECTION>>. The database commit takes place on all currently open database connections>. The statement COMMIT WORK> also closes the current SAP LUW> and performs the associated actions. COMMIT> statements are not allowed in AMDP> methods. Latest notes: A simple database commit in an ABAP program is generally done using the statement COMMIT CONNECTION> >, where the standard connection can be specified using default >. The database LUW can be monitored by the application log> by using the function module DB_COMMIT>>, if required. Apart from the database commit itself, using the statement COMMIT WORK>> also has certain other consequences with respect to the SAP LUW>. All 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. NON_V5_HINTS ABAP_HINT_END Database Commit on Secondary Connections Implicit deactivations of a secondary connection> or a service connection> at the end of an ABAP_ISESS > trigger a database commit in the transaction context of this database connection>. For more information, see Database Connections>. If the ABAP_ISESS is switched on the standard connection>, there is no database commit and no database rollback>. END_SECTION VERSION 5 OUT