As soon as a transparent table record has to be created or modified (or removed), you have to consider the fact that R/3 is a multi-user system.Thus before changing any data we must claim it for the changes. The SAP R/3 Lock-server reserves and releases data for all using processes. A Lock-object has to be created to claim records from a table. See "Data dictionary maintenance", SAP menu => Tools => ABAP Workbench => Development SE11), select radio-button "Lock object". When creating a Lock-object SAP creates two function building blocks: ENQUEUE_NNNN and DEQUEUE_NNNN, (NNNN is the name of the created Lock-object). The ABAP can call ENQUEUE_NNNN to lock the object and DEQUEUE_NNNN to release it again.

Note: there is a function module DEQUEUE_ALL as well, it will "dequeue" whatever your program has set using "enqueue".

Of course it would be very nice to show who is locking the entry. If the system returns a SY-SUBRC = 1 (FOREIGN_LOCK) the system variable SY-MSGV1 contains the SAP user name of the person who is locking it.

If you want to use the SY-MSGV1 variable above, copy its contents to your own variable first and then do the MESSAGE A100 ... statement.

*---------------------------------------------------
*  FORM LOCK_ALL
*---------------------------------------------------
*  Locks all claims for the current trader. This way all relevant
*  claim headers will be locked.
*---------------------------------------------------
*  -->  TRADER      The trader number that should be locked
*  -->  SWITCH      Flag indicating action: "ON" or "OFF"
*---------------------------------------------------
FORM LOCK_ALL USING TRADER LIKE YF023-YTRDNO SWITCH.

DATA: L_YCLAIMNO LIKE YF023-YCLAIMNO,
  L_LOCK_USER LIKE SY-MSGV1.

  CLEAR L_YCLAIMNO.
  CASE SWITCH.
    WHEN 'ON'.
      CALL FUNCTION 'ENQUEUE_EYF023'
        EXPORTING
          MANDT          = SY-MANDT
          YTRDNO         = TRADER
          YCLAIMNO       = L_YCLAIMNO
        EXCEPTIONS
          FOREIGN_LOCK   = 1
          SYSTEM_FAILURE = 2
          OTHERS         = 3.
      IF SY-SUBRC NE 0.
* Can't be locked, ABANDON SHIP !
        L_LOCK_USER = SY-MSGV1.
        MESSAGE A100 WITH 'Claims in use by user' L_LOCK_USER.
      ENDIF.
    WHEN 'OFF'.
      CALL FUNCTION 'DEQUEUE_EYF023'
        EXPORTING
          MANDT    = SY-MANDT
          YTRDNO   = TRADER
          YCLAIMNO = L_YCLAIMNO
        EXCEPTIONS
          OTHERS   = 1.
  ENDCASE.
ENDFORM.

Locking entries that do not exist... yet. There is no actual check on database objects or table entries when locking an entry. This article should clarify a few things about how locking works...

It's also possible to lock a table entry without it physically being there. This may sound a bit odd, but is very useful. When you create a new "object", you can lock it's key fields in the table. Whenever someone else tries to create your "object" with the same key, the entry will not be available in the table, but the locking will still fail. An alternative would be to create the object and store it, followed by a lock. Which would mean you always store your object before doing anything. Shame, unnecessary and introducing a chicken-egg problem (like: lock the entry you are about to store... for locking). Lean on the locking mechanism here.

Locking multiple records.

Locking doesn't have to be about single entries...

Lets assume a lock entry like EMMARCE, which locks plant data for the material master. The lock arguments for this object are client, material number andplant. If you want to lock all plants for a certain material number, just leave the plant argument blank. The system will assume that you want to lock all plants. Or even: lock the whole contents of MARA using the lock object EMMARAE with no value for the material number. That should really piss people off.

TABLES: MARA.
CLEAR MARA-MATNR.

CALL FUNCTION 'ENQUEUE_EMMARAE'
  EXPORTING
    MANDT          = SY-MANDT
    MATNR          = MARA-MATNR
  EXCEPTIONS
    FOREIGN_LOCK   = 1
    SYSTEM_FAILURE = 2
    OTHERS         = 3.

IF SY-SUBRC EQ 0.
  MESSAGE I999 WITH '(The whole of) Mara locked !'.
ELSE.
  MESSAGE I999 WITH 'Someone is using MARA'.
ENDIF.

Examples (standard SAP)
Some nice re-usable examples of lock object usage:

• When a program should only be run by one person at a time, here's a way to ensure it does: use lock object ESTERM to lock the transaction code (try ENQUEUE_ESTERM) or maybe lock the actual program name in ES_PROG.
• If a newly created table needs to be locked, but you don't want to create a lock object for it (doesn't get used too much or something), you could use E_TABLE, which would lock the whole table. Or you could even specify a variabele key VAKEY to lock only parts of the table.
• If, for some reason, you don't want the same user to start something up twice at the same time, have a check on lock object E_USR04

• Prev
• Next