Logical Lock Vs Physical Lock in SAP


This morning I had a chat with an ABAPer who has few months of experience after training. While discussing he said if a table is ENQUEUED (locked for change) in one session, no one else can modify/update that table. I tried to explain that the statement is not completely true. This post is an extension of that conversation.

There are quite a few good articles and blogs on Locking Concept. We are not going to sing the same song here. Today we would focus our discussion on just two words, Logical and Physical.

The literal meaning of the two words are:

Logical : Logical describes something that comes from clear reasoning.

Physical :When something is physical it’s really there.

If you ask anyone, what is the difference between Database Lock and SAP Lock, the knee-jerk answer is Database Lock is a Physical Lock and SAP Lock in a Logical Lock. For seasoned and experienced consultants, it is not difficult to assimilate and understand these two words. But freshers and newbies might have some questions which they are reluctant to ask their seniors.

Without wasting any time, let us start our mission.

Can two ABAPers open the same program in SE38 in change mode in the same client and system? Or can two functional consultants open the same sales order in VA02 (change mode)?

A picture is worth a thousand words. Let me demonstrate it in some images.

Check, I have opened program ZSAPYard in one session.
Lock Concept in SAP ABAP

Check the lock in the T-code SM12 shows I am inside the program in change mode.

Lock Concept

Now check this image.
SAP Lock in ABAP

Q: How can I be in editable/change mode for the same program in the same system and client?
A: Super-ABAPers have the power of ‘/h’. 🙂 Debugger. Yes

The SAP Lock would try to throw the error message that a lock is already set for the program, but you can always bypass the error message and force the system to pretend that everything is normal and do not spit any venom.

You just need to hit ‘/h’ and hit enter in the same program in the second screen in SE38 in change mode a second time. Then put a dynamic breakpoint at statement ‘MESSAGE’.


14 15

When the system would identify that a Lock is already there for the program and it would try to throw the error message, just use your debugging skill to get past the error (put the cursor on the next executable line and jump to that line without allowing the error message line to be executed).

Menu: Debugger -> Goto statement  (Shift + F12) (This helps to jump statements)

Get past the error message at a couple of places as shown above.

Boom.. You are now editing the same program in two screens in the same client in the same system.

Whether you would be able to change and activate in both the editable screen, you need to try it yourself to find it out. Let us know whether you were able to activate the changes in both screen. We would be happy to reveal, what we found.

Also Read: Everyday SAP Security Breach.

What are we trying to prove here?
SAP Lock is Logical. Even though the program was logically locked for editing, still we forced it to be open for editing in another session. How illogical!! Isn’t it?

Logical means the developer has to use his discretion and handle the locks logically. If someone has already locked something, if you want, you CAN make change simultaneously. But whether you should be changing something when someone else is trying to change at the same time? That is the logical question. SAP Locks are not physical.

Let us look another example. This would make the picture clearer.

I am locking the custom table in change mode in SM30.


Check the logical SAP lock in T-code SM12.


Now, I wrote a program to check if the table is locked. Then illogically I decide, even if it is locked, I do not care. Let the system be inconsistent. I want to update the table.

See, I am updating the table when SY-SUBRC <> 0.
Foreign Lock

Will I be able to update the table?

Untitled2Yes. Even if someone else is simultaneously editing the table, I can update the table at the same time. SAP Locks are only Logical and it needs the programmers discretion to use it properly. Check the Process flag, modified by, date and time are updated successfully for the PO item 10 which is in the WHERE clause of the UPDATE statement.

Hope now, you understand what does Logical Lock means.. 🙂

Also Read: Are you a Lazy ABAPer?

Change our focus to Physical now.

For our freshers: Database locks are set by data changing SQL statements such as INSERT, UPDATE, MODIFY etc. These are physical locks and are held until the SQL statement COMMIT is reached. Once the COMMIT statement is executed the DB lock is released.

Let us see in pictures what it means.


I have written a program to update a custom table. I set a breakpoint at COMMIT statement.

Execute the program in one session and the execution stops at COMMIT statement. Since the database executed the UPDATE statement, a database lock is set by the database. We can check the database lock using T-code DBACOCKPIT (follow the path highlighted in the below image). If you do not have access to this t-code, go to your Basis team and ask them to show you this lock.

How to check Physical Lock

Now let us run the same program in another session and set our breakpoint at the UPDATE statement.

Remember, the first debugger in the other session is still there at COMMIT statement i.e. the Physical database logic is still active as COMMIT statement has not been executed.

Database Lock

You would find that even if you hit F5, F6 or F8, you cannot get past the UPDATE statement for the second run. This is Physical. No matter how hard you try, you cannot UPDATE the same table if the first lock is not released.

I walked to the washroom, went to the cafeteria and fetched a glass of water and returned to my desk (6 to 8 minutes). The second session was still trying to get past the UPDATE statement. I came back and executed the COMMIT statement in the first debugger and boom, the UPDATE statement is executed on the second screen and waiting on COMMIT statement.

As soon as COMMIT WORK statement is executed in the first debugger, the Lock is released and the second session Locks it again as the UPDATE statement is finally executed.

DB Lock

Hope you understand the essence of Physical Lock now. It is like the real Physical lock which can be opened and closed with the key one at a time. If one key is entered in the lock hole, no other key can lock or open it.

In straight words. if there is a Physical Lock (Database Lock) on a table, it cannot be updated/changed in any other session. Period.. 🙂

For your reading pleasure, you can refer to this external link for the R/3 Lock Concept.

Updates from Experts

Scott G. said:

It’s not an SAP thing. The locks in SAP are logical, in that you hold your locks by building function modules for Enqueue and Dequeue (SE11) and see the locks in an online report (SM12).

The actual lock is up to how you configure your database that the data dictionary sits over. You could set your database to row locking, field locking, or even table locking.

But SAP from a software perspective is row locking.

Again – that’s a code thing. If I built a table called ZSCOTT and write an ABAP program to modify fields in a row (Update Set Where) but in my code, I do not enqueue ZSCOTT, then you and I could both be changing fields in the same row and whoever hits SAVE first wins. I know that sounds hokey, but it is not.

SAP Data Dictionary only controls the database with ODBC/JDBC connectivity. It’s not the database itself, per se. Hope that makes sense. If not just let me know and I will try and explain it better.

BJ Torres said:

SAP lock is an application lock. You can alter the behavior in the application layer (ie. skipping the subrc check via debug). The DML lock is a DB locking mechanism. Due to the strict ACID principle, you cannot cheat your way into clearing the lock like what you did in SAP (which relies on the DB to maintain ACID). (Please check the comment section below for full feedback)

Alessandro Arcari said:

Logical locking an entire table should be an exceptional case. I would distinguish between update locking and read locking

If you want to get such useful articles directly to your inbox, please SUBSCRIBE. We respect your privacy and take protecting it seriously.

If you liked this post, please hit the share buttons and like us on facebook.

Thank you very much for your time!!


    • Thank you very much Venkateswaran. It is a huge compliment and it means a lot to our Team.

      Appreciate your motivational words.

      Please keep visiting.

      Team SAPYard.

  1. hi, what if i want to editable/change mode for the same program in the different system and different client? ( different client means for suppose my client:120 uname:abap system:abc same server and client :120 uname: yard sytem: def )

    very good posts from your end, keep it up.
    kindly discuss the same as above mentioned..!

    thank you.

    • Hi Mahesh – Thank you very much for your thought.

      Right now, we do not have a landscape to test what you have suggested. But we believe, it should allow you to edit. Have you tried it? Please share your experience, if you have tried. 🙂

      We will update our findings.

      Team SAPYard.

  2. Just a feedback on the physical lock.

    Compared to the enqueue that you did above, the DML lock with not hold the whole table as lock. It will allow you to do DML transactions (insert, update, delete, select (to some extent)) even if there’s an open DB transaction that is not committed. The DML transaction will be stored in the undo tablespace / rollback segment until a commit or rollback. What happens is that your transactions are placed in a holding area until there’s a commit or rollback. Until the data is committed, the transaction is not yet posted. Unlike SAP lock on whole table (Enqueue without key), DB will not lock the whole table.

    Now, what you encountered in your example is a deadlock situation wherein you are trying to update the same records using the same keys in two different sessions. It will cause one session to wait for the other session to commit which is why we use the SAP locks to avoid that from happening or at least inform the user that the current key is currently locked to another session. Like what you did in the SAP lock, there’s also a way in the DB side to delete the locks but it’s stricter than SAP locking. You have to kill the deadlock session for the other to continue essentially removing the conflicting session.

    SAP lock is an application lock. You can alter the behavior in the application layer (ie. skipping the subrc check via debug). The DML lock is a DB locking mechanism. Due to the strict ACID principle, you cannot cheat your way into clearing the lock like what you did in SAP (which relies on the DB to maintain ACID).

    • Dear Torres – Thank you so much for providing your valuable insight. You made our concept clear on deadlock situation.

      We will try to lock the Physical lock with one key in one session and try to update the same table with another key in another session. That would make everything clear.

      We will update our findings.

      Thanks again.

      Team SAPYard.

  3. Great Post. But i have seen Two tables are accessible at the same time when different users are logged in different application servers. I don’t know why that happened but it shouldnt be.


Please enter your comment!
Please enter your name here