ABAP: About implicit vs. explicit db Commit

Transferred from Http://blog.163.com/[email protected]/blog/static/1394892972011611111559962/#userconsent #
1. Explicit D B Commit

The explicit DB commit does not have a corresponding ABAP statement to execute the DB commit, which is done by the usual statement Commit work. In a DB LUW, we were opened with that DB and ended in DB commit.

2. Implicit DB Commit

Implicit DB commit does not have a corresponding ABAP statement to tell the system (Okay, you give me a sneak model commit). Implicit DB commit is an additional effect of many "not paying attention" user/system operations, summarizing the actions that can trigger an implicit db commit:

(1) When the system displays a SAP screen

(2) When the system sends a dialog message(Okay:e,s, I; NO:A,X)

(3) Whenever there is synchronous and asynchronous RFC calls

(4) With call transaction <tcode> or SUBMIT <program> statement

So, from the mistakes I made in the previous year, I can also know that if we do not manually add a commit work to the database operation statement, when the program ends (that is, send msg or selection screen, etc.) will be automatically db Commit;

At the same time, it is also very important that rollback can only operate in the same DB LUW, and if the DB LUW is a commit, it will not be restored.

At the same time, debug will automatically make a commit of direct db LUW (note, non-update FM or perform <> on commit), so debug will never find the answer.

3. DB Commit and SAP LUW

Because of the implicit DB Commit, when a db LUW is closed and the physical lock of the DB is released, we need to define the SAP LUW in our Dynpro program, which requires the SAP lock mechanism and cannot rely on the DB lock mechanism;

At the same time, we know that the end of an SAP LUW is marked with the ABAP statement of commit work, so it is clear here that commit work will have the following effect on the principle:

(1) If there is an open db LUW, then the DB LUW will be ended

(2) The current SAP LUW will be closed

Also, as mentioned above, if we are not using the direct database for the newer technology, but instead use a new technology such as Update FM or perform <> on commit database, that is to say we encapsulate the database update in an SAP LUW, Does the implicit DB commit above affect the database update request in this SAP LUW?

No.

Because the implicit commit above is for DB commit, not for SAP commit. If you want to perform the database update request in SAP LUW above, you must use an explicit DB/SAP commit such as commit work.

So, this time will have to pay attention to, especially if we use the link program in the procedure, that is involved in different sessions of the relationship between different programs, at this point, it must be ensured that the database update request in the previous session is released ( Commit), if not commit, then unfortunately, your database update will not be executed, this time although there is an implicit db commit, but it does not work.

4. Test examples

As for the four classes that can implicitly trigger DB commit, as well as commit and rollback in the same DB LUW, we can create many of our own test programs to test.

This is only a test of Db/sap Commit under the frequently used update technology.

The program completes:

Update two records of a database table using perform <> on commit.

Tested separately:

(1) Use a msg: No implicit db Commit will occur and database update request is not performed

(2) Use x msg: No implicit DB Commit occurs and database update request is not performed

(3) Use e msg: An implicit DB Commit occurs, but the database update request is not performed

(4) Use S msg: do not occur implicit DB Commit, run to below to perform database update request

(5) Use I msg: An implicit DB Commit occurs, returns and runs below to continue, perform database update request

(6) Using Link program: An implicit DB Commit occurs, but the database update request is not performed (also similar to leave to transaction)

*& ——————————————————————— *
*& Report Ztest_commit_1
*&
*& ——————————————————————— *
*& Commit
*& DB Commit & SAP commit
*& ——————————————————————— *

Report ztest_commit_1 NO Standard PAGE HEADING.

*-data & Types
DATA:
Gs_table1 type Zoffering_soluti,
Gs_table2 type Zoffering_soluti,
Gt_table type Table of Zoffering_soluti.

Start-of-selection.

Clear:gs_table1,gs_table2.

* *. Modify the record 1
*1-1. Retrieve the data from table
Clear:gs_table1.
SELECT Single * from Zoffering_soluti
Into Gs_table1
where solution_id = ' Ztest_01′and
Land = ' DE '.
*1-2. Modify the description
Gs_table1-text = ' ztest_01 from program ztest_commit_1′.
*1-3. Using Update subroutine
PERFORM frm_upd_table on COMMIT.

* * . Modify The record 2
*2-1. Retrieve the data from table
Clear:gs_table2.
SELECT Single * from Zoffering_soluti
Into Gs_table2
where solution_id = ' Ztest_02′and
Land = ' DE '.
*2-2. Modify the description
Gs_table2-text = ' ztest_02 from program ztest_commit_1′.
*2-3. Using Update subroutine
PERFORM frm_upd_table on COMMIT.

IF 1 = 1.
" A type:no Update the DB (Interrupt The program)
"MESSAGE ' MSG A would terminate the execution of db-update ' type ' a '.
" " X type:no Update the DB (Interrupt The program)
"MESSAGE" MSG x would terminate the execution of db-update ' type ' X '.
" " E type:no Update the DB (Interrupt The program)
"MESSAGE" MSG E would terminate the execution of db-update ' type ' E '.
" S type:update the DB (not Interrupt the program)
"MESSAGE" MSG S would not terminate the execution of Db-update ' type ' s '.
" I type:update the DB (Interrupt the program, but would go back and then commit work!)
"MESSAGE" MSG I would not terminate the execution of db-update ' type ' i '.

"Leave to Program (won't execute the update-request by Perfrom-on-commit)
Submit ztest_alv_1.
ENDIF.

. DB Commit
COMMIT work.
IF SY-SUBRC = 0.
MESSAGE ' Your program executed successfully! ' TYPE ' S '.
ENDIF.

*& ——————————————————————— *
*& Form frm_upd_table
*& ——————————————————————— *
* Using Update subroutine to update the Table
* ———————————————————————-*
FORM frm_upd_table.

* Modify the DB Table using work area 1
IF Gs_table1 is not INITIAL.
MODIFY Zoffering_soluti from Gs_table1.
IF SY-SUBRC <> 0.
MESSAGE ' Your Modify is failed! ' type ' A '.
ENDIF.
ENDIF.

* Modify the DB Table using work area 2
IF Gs_table2 is not INITIAL.
MODIFY Zoffering_soluti from Gs_table2.
IF SY-SUBRC <> 0.
MESSAGE ' Your Modify is failed! ' type ' A '.
ENDIF.
ENDIF.

EndForm. "Frm_upd_table

In addition, it must be explained here: because it is the execution of the commit, it is not like direct, after the completion of the first update and then to do the second update, it is at the end of the commit work before going to execute, that is, if you do not use the separate gs_ Table1 with Gs_table2, on the contrary for example using only one gs_table then it will only update the last one that was obtained.

In fact, this is also the most basic on commit or update FM.

ABAP: About implicit vs. explicit db Commit