Record Locking in T24: What a Stuck Lock Means

Record locks are one of those T24 problems that sound simple until you are the person being asked to clear one in production. A user cannot open a record. A process is waiting. A batch step appears to be stuck. Someone says, "It is locked. Can you just clear it?" This is usually said in the tone of a person asking you to move a chair, not interfere with transaction safety.

Sometimes the answer is yes. Sometimes clearing the lock is the fastest safe way to restore service. But the word "safe" is doing a lot of work there. A lock is not just a nuisance. It is part of the mechanism that stops two processes from changing the same record at the same time. Annoying, yes. Also the reason the database does not turn into interpretive dance.

The skill is not knowing that locks can be cleared. The skill is knowing when the lock is stale, when it is active, and what must be checked after the intervention. Clearing is easy. Knowing whether you should clear it is where the job starts looking like a job.

Why locks exist

A T24 record lock usually means a process has read a record with the intention of updating it. The system holds the lock so that another process cannot write over the same record halfway through the operation. It is the software equivalent of putting a hand over your notebook while you are still writing in it.

That is not a bug. That is protection. Without locking, two sessions could read the same starting state, apply different updates, and leave the final record depending on whichever write happened last. In a banking system, that is not a harmless race condition. It can become a business defect with a meeting invite attached to it.

A lock only becomes a support problem when the holder cannot complete normally. Common causes include:

• A user session ended unexpectedly while editing a record
• An online process failed before releasing the lock
• A batch job stopped mid-step
• An integration process waited too long or disconnected
• A long-running process is still active but looks stuck from outside

Active lock or stale lock?

The first question is not "How do I clear this?" It is "Does the process that owns this lock still exist?"

An active lock belongs to a session or process that is still doing work, even if that work is slow. Clearing that lock can allow a second update to enter while the first one has not finished. That is where invisible data problems begin, which is rude because invisible problems have excellent survival skills.

A stale lock belongs to a process that is gone or cannot recover. In that case, the lock is no longer protecting a live update. It is blocking work without adding safety, so clearing it may be the right action.

The hard part is that the user report rarely tells you which one you are dealing with. "I cannot access the record" is a symptom, not a diagnosis. It is the opening sentence of the mystery, not the final page.

What to check before clearing a lock

Before you remove a lock, build a small amount of evidence. You do not need a committee meeting. You do need enough confidence that you are not interrupting a valid in-flight update. This is one of the rare support situations where "just do it" is not a methodology.

1. Identify the locked record and the file it belongs to.
2. Identify the user, session, job, or process that holds the lock.
3. Check whether that session or process is still active.
4. Check whether the same user is still logged in elsewhere.
5. Check whether a related batch or interface process is running.
6. Confirm the business impact of waiting versus clearing.

If the holder is still active, the better first action is often to understand why it has not completed. If the holder is gone, clearing becomes much easier to justify. Dead sessions do not need privacy. Live ones do.

What to check after clearing

Clearing the lock is not the end of the work. It is the point where you must prove the record is still in a clean state. The system has allowed you back into the room; it has not certified the furniture.

If the lock was left behind by a failed update, the record may not be exactly where the business process expects it to be. The application may have written one field and failed before writing another. A related history, accounting, or status record may not have been updated. A workflow item may still point to the old state.

After clearing, check:

• Can the user open the record again?
• Does the record status make sense for the business process?
• Are related records in the expected state?
• Did the failed process leave an error, unauthorised item, or repair item?
• Does the next downstream process pick the record up correctly?

A cleared lock with no follow-up check is not a resolution. It is an assumption wearing a support-ticket reference.

Where DBTools fits

In TAFJ environments, support teams often use DBTools or related server-side tooling to inspect data and resolve lock situations. That makes the tool powerful, but it also makes the discipline around it more important.

Direct database-level intervention sits below the normal T24 application layer. It may not apply the same validation, audit, workflow, or business-rule checks that an online transaction would apply. That does not mean you should never use it. It means you should treat it as a controlled support action, not a casual shortcut. Shortcuts are excellent until they bypass the part of the road that was holding up the mountain.

The useful question is: if someone asked tomorrow why this lock was cleared, could you explain the evidence? If the answer is yes, you are probably operating with the right level of care.

Bad lock-handling patterns

A simple decision rule

Use this rule when the situation is tense and everyone wants a quick answer:

If the lock holder is active, investigate the holder. If the lock holder is dead, clear the lock and verify the record.

That rule will not solve every edge case, but it prevents the most common mistake: treating every lock as stale just because a user is blocked. The universe is allowed to be inconvenient without being broken.

T24 support is often about reducing ambiguity. A stuck lock is a small example of that wider discipline. The goal is not simply to remove the obstacle. The goal is to leave the system in a state you can explain.