Rule 1: There should be no COMMIT and ROLLBACK statements between changes in the main program.

More than one change block is captured in the trace, which means that there is more than one COMMIT statement in a single logical unit of work (LUW).

The tool counts the number of change blocks (that is, all INSERT, UPDATE, and DELETE statements) between two COMMIT statements. If more than one change block is captured in the trace, transactional correctness might be at risk for the statements after the first change block.

Rule 2: There should be no COMMIT and ROLLBACK statements between changes within each tRFC/qRFC.

Rule 3: There should be no changes in sRFC/aRFC unless executed in an update task.

The analyzed trace contains changes that were performed in an update task, and changes that were performed outside an update task.

The tool recognizes if a change block contains changes that are made by an update task (tables VBMOD, VBDATA, or VBHDR). If a change block contains such a change, and also contains changes that are processed outside the update task, check if all changes can be processed in the update task. Changes processed outside the update task have this warning.

A COMMIT statement is required, since updates in an update task are only triggered by an explicit COMMIT statement.

Transactional correctness might be at risk if data processing aborts when the changes outside the update task have already been committed to the database, but those performed inside the update task have not yet been committed, so check whether the changes performed outside the update task can also be performed in the same update task as the other changes.

If there is no COMMIT statement to trigger the changes in the update task, add it. Follow rules 1 and 2.

Rule 4: An explicit COMMIT statement is needed to trigger changes in an update task.

Rule 5: If some changes in the main program are executed in an update task, the others should be as well.

Rule E1: A database record might be modified without an active enqueue.

The trace contains an INSERT, UPDATE, UPSERT or DELETE statement, but there is no enqueue active when the modifying statement is executed. So, the same table record can be modified by more than one process at the same time, which can lead to inconsistencies, since isolation is not guaranteed.

Ensure that during the database modification a correct enqueue is set, by calling the enqueue function module for the lock object.

Rule E2: A dequeue might be set without an active enqueue.

The trace contains a DEQUEUE statement when there is no active ENQUEUE statement. An enqueue may not have been set, so the same table record may be modified by more than one process at the same time, which can lead to inconsistencies, since isolation is not guaranteed.

Rule E3: A dequeue is set without all parameters specified.

The trace contains a DEQUEUE statement, but the corresponding dequeue function module is not called with all parameters, so the corresponding enqueue will not be deleted. This impacts performance, since the enqueue will be held longer than required, and other work processes will not be able to modify the locked object.

The corresponding enqueue will only be deleted with the next Dequeue All, which can either be triggered explicitly (via an ABAP command) or automatically at the end of the SAP LUW, or at the end of the SAP transaction.

Ensure that all the parameters of the call of the dequeue function module are the same as in the call of the corresponding enqueue function module.

Rule E4: Modifying DB operation on a table that is not part of an active lock object.

The trace contains an INSERT, UPDATE, UPSERT or DELETE statement on a table that is not part of an active lock object.

A lock object is active when there is an active enqueue. For the table with no active lock, the same table record can be modified by more than one process at the same time, which can lead to inconsistencies, since isolation is not guaranteed.

For the table being modified, check whether there is a corresponding lock object, and modify the code so that this lock object is called via the corresponding enqueue function module. If there is no lock object for this table, create one or assign this table to a lock object that is active during program execution.

Rule E5: The changed table entry might only be locked by a shared lock.

The trace contains an INSERT, UPDATE, UPSERT or DELETE statement on a table for which only a shared lock is active at the time of the modification.

The most commonly used lock modes are “Shared Lock” (S), “Write Lock” (E), “Exclusive, not cumulative” (X). If only a shared lock is set on a data record, it can be modified by a work process other than the lock holder, so isolation is not guaranteed, and inconsistencies might occur.

Check the lock arguments in the call of the enqueue function module that locks the table to be modified. Change the lock mode to a “Write Lock” (E) or “Exclusive, not cumulative” (X). Adapt the call of the dequeue function module, since the enqueue will only be deleted by the dequeue function module if enqueue and dequeue function modules are called with the same parameters. If the lock mode is not set explicitly when the enqueue function module is called, the lock mode will be taken from the lock object’s master data (In transaction SE11, choose  Lock Object Tables Lock Mode ).

Rule E6: Data might be committed without an active enqueue.

The trace contains a COMMIT WORK statement when there is no active enqueue. Changes to the database will only be consistent after they have been commited or rolled back. Ensure that the enqueue still is active at the time of the commit. If not, isolation might not be guaranteed, and the data to be modified can be changed by another work process before the current changes are posted to the database. This can lead to inconsistencies.

Ensure that the correct enqueue function module is called before the changes to the database table, and the correct dequeue function module is called only after the data is committed to the database.

No ENQ, DEQ or DEQ ALL statement found at all. Check whether Enqueue trace was captured.

This message is issued at the end of the result list of the transactional correctness check tool, if the trace contains no ENQUEUE, DEQUEUE or DEQUEUE ALL statements, for the following reasons:

Ensure that when capturing the ST05 trace, “Enqueue Trace” is selected, so that the corresponding statements are in the trace result, and can be evaluated by the tool.