Show TOC

Object documentation_SCOPE Parameters Locate this document in the navigation structure


The application programmer uses this parameter to determine which of the two owners should actually own the lock.

_SCOPE can take the values 1, 2, or 3.


At the start of an SAP LUW two Lock Owners are created. These are the dialog owner and the update owner. With this parameter you specify the owner(s) for your lock and control its behavior during the SAP LUW.


The following values are permitted:

Meaning of the _SCOPE Values



_SCOPE = 1

The lock belongs only to the dialog owner (owner_1), and therefore only exists in the dialog transaction. The DEQUEUE call or the end of the transaction, not COMMIT WORK or ROLLBACK WORK, cancels the lock.

_SCOPE = 2

The lock belongs to the update owner only (owner_2), so it is inherited by the update task if CALL FUNCTION '...' IN UPDATE TASK and COMMIT WORK are called. The lock is released when the update transaction is complete. You can release the lock before it is transferred to the update using ROLLBACK WORK. COMMIT WORK has no effect, unless CALL FUNCTION ‘…‘IN UPDATE TASK has been called.

_SCOPE = 3

The lock belongs to both owners (owner_1 and owner_2). In other words, it combines the behavior of both. This lock is canceled when the last of the two owners has released it.

Since the _SCOPE parameter is a lock operation parameter, and not a property of the lock itself, the function module for an existing lock can be called again. So an update owner can be added to a lock with one dialog owner (_SCOPE=1) by calling the function module again with _SCOPE=2. The result of these two calls is no different to a call with _SCOPE=3.

Once the update has finished, a _SCOPE=3 lock changes to a SCOPE = 1. If a new update is required, a new update with _SCOPE = 2 is needed.

More information:

Example: Infinite Transaction with Update

Function Modules for Lock Requests


The following graphic shows the locks during an R/3 LUW in connection with the _SCOPE parameter. The diagram also shows how long the SAP locks are active (these are not the actual database locks, as described under SAP Lock Concept).

The lock remains as long as the corresponding DEQUEUE function module is called, or the transaction is ended with an implicit DEQUEUE_ALL (as displayed in the graphic).

This graphic is explained in the accompanying text.

SAP Locks and _SCOPE Values

In this example, the lock object A (that the programmer created previously in the ABAP Dictionary) is locked during the transaction by the function call CALL FUNCTION 'ENQUEUE_A'. By setting the _SCOPE parameter to 1, lock A is not passed on to the update process (it only belongs to the dialog owner E_1). The lock is released by the function call DEQUEUE_A, or at the latest at the end of the dialog transaction.

Later, the lock B, which belongs to E_2 (the update owner) (_SCOPE=2), and the lock C, which has two owners (_SCOPE=3), are requested. An update request is generated when CALL FUNCTION '…' IN UPDATE TASK is called. The COMMIT WORK calls the update process, which the locks and the update owners of locks B and C inherit. At the end of the update, these locks are released. However, lock C from the dialog owner may exist afterwards (depending on the transaction programming).

The dialog locks A and C exist until the end of the dialog transaction.

Caution Caution

If a lock with _SCOPE=2 is set, and COMMIT WORK is called before CALL FUNCTION '...' IN UPDATE TASK, the lock remains as a dialog lock (black in the overview of transaction SM12) up until this time. At this point in time, it is not yet possible to transfer the lock to an update work process.

End of the caution.

Only when CALL FUNCTION '...' IN UPDATE TASK is called and a COMMIT WORK executed, is the lock passed to the update process at a later time. It is then marked as a lock with the backup flag in the detail view of the Lock Administration (transaction SM12 Details).