Skip to Content
Technical Articles
Author's profile photo Arijit Dutta

Delete Foreign Lock Entries in Debug

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



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‘.

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.

just replacing the sy-uname is the simplest way  if you want to delete foreign locks.



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

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Rainer Lindemann
      Rainer Lindemann

      I'm appalled. You're showing how to circumvent authorization restrictions by using the debugger? To delete foreign locks?
      Never mind the disclaimer. If you do this on a productive system, you fully deserve any amount of trouble that may come your way. DON'T DO THIS.

      If you really need to unlock an object by brute force, in case of an emergency (and only then), you should much rather kill that user's session. But never just kill the lock, because now you have two concurring editing actions on the same object, and this endangers data consistency of your SAP system.

      Author's profile photo Arijit Dutta
      Arijit Dutta
      Blog Post Author

      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.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      If you don't have the authorisation to perform an action, getting around that by debugging is asking for trouble. (Like disciplinary action). You are violating your client's security policy. You're essentially hacking.

      The correct solutions are, from most preferred:

      1. Get the authorisation to terminate other users' sessions
      2. Ask someone who has that authorisation to terminate the other users' sessions
      3. Get the authorisation to delete others' locks
      4. Ask someone who has that authority to delete the locks


      Author's profile photo Michael Keller
      Michael Keller

      Rainer Lindemann: Support for your comment.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Plus 1!

      Author's profile photo Shai Sinai
      Shai Sinai

      TBH, This a good example of why users shouldn't be granted with authorizations to change values in debug in productive systems.

      Author's profile photo RON SARGEANT

      If I was your client and reading this...smh. You obviously don't identify as an extension of your client or take enterprise development seriously.
      If you don't have admin authority for something like this, you are really looking to lose your job (within a reputable company anyway).

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Arijit, you might be thinking "sheesh, I'm just trying to be helpful here by sharing my awesome solution to a real problem and all these people are ganging up on me". Unfortunately, this is the situation where good intentions are paving the road to a rather bad place.

      I think Matthew Billingham listed the right steps in his comment but just to add more context. If you don't have access to certain functionality, then either the client doesn't want you to have it or it was a mistake in setting up your role. In a test system, all you need to do in such case is ask for access. If you're still refused, then you raise this issue with client, manager, whomever, so that someone assists you with resolving this. Wait for assistance and don't just jump into debugger.

      In a productive system, no one should have change access in debugger (other than in a Firefighter role maybe, even there it's questionable). Issues like you describe (a person locked an object and left for the day) can happen occasionally. The way this should be handled in a productive system, whoever needs the object unlocked would open a ticket and then a person responsible for system support would go into SM12 (using a FF access, if necessary) and unlock using that transaction. Usually a note would be sent to the "offending" user to inform them what happened and asking not to do that.

      Debugger is a powerful tool but using it for some things, like working around authorization very clearly set by the client is unethical. And it's not some life or death situation that could justify a transgression.