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.
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’.
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.
Will I be able to update the table?
Yes. 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.
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.
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.
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!!