SM12 is the transaction code to remove the lock entries, this will happen when two process are searching the same source then you may have locking problem. Then you will get the error message 'currently locked by the user', then you can go to this tcode, on tool bar your having
lock entry ---> list all ---> delete, then your locks
can be removed.
Explanation: SM12: Tcode for lock management
Managing lock entries lets you monitor your system with regards to lock logic. You can determine which locks are being used currently. Locks that have had the backup flag set are highlighted in color
You can detect and correct problems by deleting locks that you no longer want. You can also later analyze the cause of lock table overflows using the History.
Mode: You can see which type the lock object is (S: shared lock, E: exclusive lock, X: exclusive and not cumulative, O: optimistic lock). The various lock modes are described in section Functions of the SAP Lock Concept.
Table: The Table column contains the tables in which rows are locked.
Lock argument: The Lock argument column, you can see the argument (key field) of the lock entry. This corresponds to the entries in the lock table.
The lock entries are shown in different colors:
Blue means that the locks have already been transferred to the update task (see also The Owner Concept), with the result that the backup flag is set. These locks are also rewritten to the lock table when the enqueue server is restarted.
Black means that the lock (still) belongs to the dialog owner. The backup flag is not set.
By choosing Edit -> Sort by, you can display the locks according to user, time, table, or host system (host).
By double clicking a lock entry, you can display detailed
information, including the host name and number of the SAP System in which
the lock was generated.
Further notes:
You should never delete a lock when you are unsure and/or don't know what is this lock for. You may generate an inconsistence.
Locks are put on table and / or table entries when a process needs exclusive access to this DB table and/or record. Removing this lock could let for example another process to change the same data while the process is still running thus generating inconsistence.
Always try to match a lock with a process in SM66, a background Job in SM37, a DB session, in ST04 / detailed analysis / sessions or a user logged in with AL08/SM04.
If you have identified from where does the lock come, then first try to kill the job, then the related process, then kick the user out (best would be to ask him what is he doing) and finally the DB session. Usually one of this action will remove the lock cleanly.
If it is not the case, deleting a lock in SM12 would be the very last option.
