SAP Object Locked by Another User: What It Means (SM12)
An object locked by another SAP user and an object you have no rights on feel exactly the same: everything stops, and you cannot type anything. Yet the two mechanisms have nothing to do with each other. The second one is a permission you are missing. The first one is a protection doing precisely its job, and it holds because someone else is working on the same record as you. Confusing them means looking for the exit on the wrong side. And sometimes breaking something while you look.
- The reversal: a lock is not a failure. It is the mechanism that stops two people from overwriting each other’s work on the same record.
- This is not your module talking: locking lives in the technical Basis layer. Hence an identical message in MM, PP, SD, PM or EWM.
- The most useful information is already on your screen: the message names the user holding the lock. A quick message to that person settles most cases.
- Four modes exist (S shared, E exclusive, X exclusive non-cumulative, O optimistic), not two. The one you meet when you are blocked is the E.
SM12is a reading tool before it is a button: who holds the lock, on what, since when. Reading is free, deleting is irreversible.- The right question is never “since when”: it is “is the session behind it alive”. And it belongs to Basis, not to you.
Object locked by another user: what SAP is actually telling you
The message is not announcing a failure. It is announcing that another session already holds this record in change mode, and that SAP refuses to let you write over it. Nothing is broken, the data is intact. Someone got there before you.
This mechanism belongs to no functional module. It lives in the technical Basis layer, in the shape of the lock concept, managed by the enqueue server. Hence a rigorously identical message whether you sit in MM, PP, SD, PM or EWM: it is not your module talking, it is the foundation shared by all of them.
SAP tells you the object is locked by a user, and it gives you that user’s ID. This is the most useful information on the screen. Not an error code to paste into a ticket: the name of a person to talk to.
The first 2 minutes: the reflex before any action
You are blocked, you want a way out now. Here is the sequence that moves things forward without destroying anything. None of these steps changes a single thing in the system.
-
1Write down what you were doing
The transaction you used, and above all the exact key of the object concerned (order number, material, production order). Without that key, nobody will be able to help you.
-
2Read the message again
It names the user holding the lock. That is the piece everyone skims over, and the one that settles most cases.
-
3Identify the person
A colleague from your own team, someone from another team, or an ID you do not recognise. That last case changes everything, and we come back to it below.
-
4Contact them
One message is enough. In most situations, the person left a screen open and no longer needs it. They exit the transaction, the lock drops, you go through.
-
5Wait, then try again
A lock is not a queue: SAP will not tell you when it is released.
-
6If nobody answers, escalate
Do not try to force it. The escalation protocol is described below, and it is short.
This sequence looks slow next to “just delete the entry and move on”. It is the fastest one: it is the only one that does not create a second problem while solving the first.
Why SAP locks: a lock is not a failure
The job of a lock is to stop two parallel transactions from changing the same database record at the same time. Without it, two people entering data simultaneously on the same object would overwrite each other’s work, silently, and the database would end up inconsistent. A lock is therefore the only thing that guarantees what you save is what you actually typed.
One point deserves to be straightened out right away, because the opposite is written everywhere: there are not “two types of locks”. The SAP lock concept defines four of them, plus modes that only perform collision checks.
| Mode | What it means in practice |
|---|---|
| S (shared) | Several users can access the data in display mode at the same time. Further S lock requests are accepted, because they accumulate. |
| E (exclusive) | One user accesses the data in display and change mode. The same user can request this lock again, it accumulates. As soon as another user requests it, there is a lock collision. This is the one you meet when you are blocked. |
| X (exclusive non-cumulative) | Read and write access, but this lock can only be requested once by the same transaction. Any further request causes a collision. |
| O (optimistic) | Behaves like a shared lock at first, and can be converted into an exclusive lock. |
On top of these there are other modes which, unlike the ones above, only perform a collision check without actually setting a lock. They therefore do not appear in the lock table.
The logic fits in one sentence: displaying together is allowed, changing together is not.
SM12: a diagnostic tool before it is a button
SAP keeps locks in a central table, held in the main memory of the enqueue server. There is only one such table for the whole system: that is precisely what allows a lock set from any application server to be seen by all the others. And it is transaction SM12, on the Basis side, that administers it. This is not a database table: you will not read it with your usual tools.
SM12 is first and foremost a way to read. It answers three questions, and those three answers are almost always enough:
-
1Who?
The user holding the lock.
-
2What?
The lock object and the argument, meaning the precise record being held.
-
3Since when?
The time it was set. A three-minute lock and a six-hour lock do not tell the same story.
Reading is not deleting. These are two gestures that the screen places a few centimetres apart and that could not be more different. The first one is free, the second one is irreversible. The most frequent case on the business side is also the most harmless: a table left open in maintenance by someone who walked away from their desk without closing the screen.
Who is allowed to release a lock, and why it is probably not you
Two things need separating, and everyday vocabulary mixes them up constantly. An authorisation block is SAP telling you that you have no right to perform this action, whatever the state of the system. A lock is SAP telling you that you do have the right, but that someone is already on it. The first is settled with roles and authorisations. The second is settled with a conversation.
Deleting an entry in the lock table is an administration operation reserved for Basis. If you are a key user and you have no access to SM12, this is not an oversight in your profile: it is a design decision. The gesture is destructive and has no safety net, which is a good reason not to hand it out widely.
The ghost session: the only case where releasing can be defended
A lock stays set until the matching release function is called, or until the transaction ends and releases everything. In other words, it does not expire after a delay. There is no timer. As long as the session that set it does not end properly, the lock holds.
This is where what people commonly call a ghost session comes from. It is not an official SAP term, it is a description: a session whose owner is no longer really working, but which was never closed properly. The machine crashed, the person went on holiday with a screen open. The lock does not know that. It does what it was designed to do: it holds.
The most deceptive case is a session stopped in the debugger. Seen from the lock table, it looks like a live session, because from the system’s point of view it is one: its transaction is neither finished nor released. It is for that kind of nuance that the diagnosis belongs to someone who sees the system landscape, not to the person stuck in front of their screen.
The deciding factor is never “how long has this lock existed”, but “is the session behind it alive”.
A six-hour lock set by a job that is still running is perfectly healthy. A ten-minute lock set by a machine that crashed never will be.
When NOT to release: the situations where you destroy a colleague’s work
Releasing a lock does not “unblock” anything. It takes a protection away from someone who is still inside. At the other end, that person loses the entry they were making, with no warning and no way to recover it. They will find out when they save, and nobody will connect it to what you did.
- A human is behind it. They are entering data. You are not saving time, you are destroying theirs, and they will start over.
- You do not know who is behind it. Uncertainty is not permission. If you cannot answer “is this session alive”, you cannot decide.
- The lock belongs to a background job. There is nobody to call, and that is exactly the trap.
When the lock is held by a background job, no human ID is waiting for you at the other end. The temptation is strong to conclude the lock is orphaned. It is the opposite: the job is running, it is working, and releasing its lock mid-execution leaves it writing into a system that no longer protects it. You are not unblocking a screen, you are breaking a job, and the damage is rarely measured the same day.
There is one more subtlety: when a transaction ends, its locks are passed to the update system and kept until the update runs to completion. A lock that survives a few moments after the user has left their screen is therefore not necessarily abnormal. It may be protecting the end of the work.
Escalating properly: what to send Basis to be taken seriously
A key user who escalates well gets an answer quickly. A key user who writes “SAP is stuck” triggers a round of back and forth. The difference sits in the content of the first message.
-
1The transaction and the exact action
What you were doing at the moment of the block, not a rephrasing of it.
-
2The object key
The precise number. That is what lets them find the lock without calling you.
-
3The user named in the message
Copy the ID exactly as it appears.
-
4What you have already tried
“I contacted the person, no answer for 40 minutes” is worth more than any technical description.
-
5The real urgency, and why
A delivery leaving tonight is not an order to be entered sometime this week. Say which of the two it is.
-
6Your question, not your solution
Ask “is the session behind this lock still alive”, not “please delete the lock”. That is the question Basis can answer and you cannot.
This last point is the most useful one: it puts you on the side of someone who has understood the mechanism, and leaves the decision to the person who has what it takes to make it.
Frequently asked questions
What does “object locked by another user” mean in SAP?
It means someone else already holds this record in change mode, and that SAP is stopping you from writing over it. It is not a failure and nothing is lost. The message names the user concerned: in most cases, a message to that person settles the situation in two minutes.
How do I find out who locked an object in SAP?
The message on screen already contains the ID of the user holding the lock: that is the first thing to read. On the Basis side, transaction SM12 shows the lock table and tells you who holds what, and since when, without deleting anything.
Can I delete an SAP lock myself?
Probably not, and that is good news. Deleting a lock is an administration operation reserved for Basis, because it is destructive and has no safety net. If you have no access to SM12, it is not an oversight in your profile, it is a design decision.
What happens if I release a lock while a colleague is working?
They lose the entry they were making, with no warning and no way to recover it. They will only see the problem when they save, and they will never connect it to what you did. That is why “who is behind this lock” gets settled before you act, never after.
Does an SAP lock release itself?
Not after a delay: there is no timer. A lock stays set until the release function is called, or until the transaction ends and releases all of its locks. That is exactly why a session that was never closed properly leaves a lock in place indefinitely.
What is the difference between a lock and an authorisation problem?
An authorisation problem means you have no right to perform this action, whatever the state of the system. A lock means you do have the right, but that someone is already on the record. The first is settled with roles and authorisations, the second by waiting or by talking to the right person.
What is a ghost session in SAP?
It is a common expression, not an official SAP term. It describes a session whose owner is no longer really working, but which was never closed properly: crashed machine, hard power off, screen left open. The lock holds because the transaction was never ended. Only someone who sees the system landscape can confirm that a session is really dead.
The lock is working for you
A locked object is not an incident, it is the system protecting someone’s work. One day, it will be yours. The only question worth asking is not “how do I delete it” but “is the session behind it still alive”, and it belongs to Basis.
Next time the message lands, make one single move: read it again, find the ID, and write to the person before you write a ticket. If you want to see what sits behind that border between your scope and technical administration, the Basis world starts exactly there.
Keep reading
SAP availability check (ATP): sales order not confirmed
SAP availability check (ATP): why your sales order is not confirmed The stock is right there on your screen, the sales rep is calling, and the confirmed quantity on the...
Michael A.
SAP Credit Block: Release a Blocked Sales Order (VKM1, VKM3)
SAP Credit Block: Release a Blocked Sales Order (VKM1, VKM3) and Understand OVA8 You create a sales order the way you do a hundred times a week, and instead of...
Michael A.
SAP EWM Wave Management: Waves, WT and WO Explained
SAP EWM Wave Management: Mastering Picking Waves A misconception runs through almost every team I meet: "my wave creates my picking tasks." It does not. SAP EWM wave management builds...
Michael A.
SAP BOM and Routing: Create the Pair (CS01, CA01)
SAP BOM and routing: understand and build the BOM / routing pair First thing to get straight, because this is where everyone stumbles: in SAP, a bill of materials has...
Michael A.