We know, we can manually delete ours lock using t-code SM12. In some project, you might not have access to t-code SM12 at all. In some, you might have access to t-code SM12 but only in display mode. And in some clients like I am in now, you can only delete your locks, not the foreign locks i.e. you cannot delete objects locked by other users.

Inspiration of this post.

Your colleague was editing an object (program) in the office at offshore. When he left for the day, he just locked his desktop (window + L) and went. He did not close the windows he was working on and also did not shut down his desktop.

At a distant land, in a different time zone, you are starting your day and you need to correct/modify the same object which your colleague has locked. You try to call him but he is not reachable; may be he is partying somewhere. 🙂

You have 3 options.

1) Park this object to be worked on some other day. Work on some other issue/development now.

2) Wait till SAP Auto Logs out the user with message ‘maximum user idle time exceeded‘ and all sessions of the users are closed.

3) Delete/Release that lock entry and start working on that object immediately.

This page is for option 3.

Disclaimer: This page is not to encourage you to delete others locks. Please use it ethically and responsibly.

[adToAppearHere]

SAP says:

Before you can manually delete lock entries, you must make sure that there are no processes active that need the objects in question to be locked (transaction, update). Otherwise, there is a danger that the objects that are no longer protected can be changed by several processes at once and, as a result, become inconsistent and incorrect.

Before you delete any lock, make sure you know what you are doing and there would not be any inconsistency.

Enough, caution. Let move on!!

Check, user is not able to edit the program as it is locked by another user.

Go to T-Code SM12. Provide the user id of the person who has locked the program and hit list.

You will get the list of all locks under his id.

Identify and select your program which you want to release/unlock. Hit the Delete icon.

Check you get the message, ‘You are not authorized to delete foreign lock entries‘.

As we know, ABAPer with debug and change role can enter and break even the safest bank lockers. Select the line you want to unlock. Type ‘/h’ at the command entry section. Hit enter. You will get ‘debugging switched on‘ message. Hit the Delete icon.

You are in the debugger mode now.

Type sy-uname. You would find your user id by default.

Now, we just need to fool the system. In the sy-uname variable, replace your user id with the userid of the person who has locked this object.

You are done. You will get a pop up confirmation message. Just hit Yes. The lock entry is gone. Without wasting any time, you can change your object now. 🙂

Earlier too, I use to delete the locks in debug mode by by-passing the validation and authorization section. But, recently, I figured out that just replacing the sy-uname is the simplest way to fool the system if you want to delete foreign locks.

Hope you enjoyed this tweak. You might also like to check our other post about changing variants in production system without Fire Fighter.

If you want to get such practical issues and resolutions straight to your inbox, please SUBSCRIBE.

Thank you very much for your time!!

Image courtesy : www.123rf.com