Quick Answer
The message “a record in the [table] table was locked by another user” means two processes tried to change the same data at the same time. Business Central locks a table during posting to protect data, and if your action waits too long for that lock, it times out. Usually you just wait a moment and retry. If it happens constantly, the real causes are long-running posting, the Automatic Cost Adjustment setting, heavy reports running during posting, or inefficient custom code, and those need an admin or partner to fix.
18+ years implementing Dynamics NAV, Business Central & LS Central
If you use Business Central, you have probably seen the table locked message at least once.
The operation could not complete because a record in the [table name] table was locked by another user. Please retry the activity.
It usually appears when you try to post a document, run a batch, or release an order. The first time, it is mildly annoying. When it happens several times a day and users are waiting a minute each time to post, it becomes a real productivity problem. The good news is that this error is well understood, and most of it is fixable. Let us walk through what it means, why it happens, and how to resolve it, from the quick user fix to the deeper admin fixes.
📋 In This Guide
Table of Contents
What the Error Actually Means
Business Central sits on top of a SQL Server database, and databases use locks to protect data. When one process is writing to a table, it briefly locks the relevant data so no other process can change the same thing at the same time. This is a good thing: it stops two users from corrupting each other’s postings.
The error appears when your action had to wait for a lock that another process was holding, and it waited too long (a lock timeout). Business Central then stops your action safely and tells you to retry. Nothing is broken and no data is lost. It is the system protecting itself, not a bug.
💼 From 18 Years in the Field
The word “another user” in the message is slightly misleading. It is often not a person at all. The thing holding the lock is frequently a background process, a scheduled report, or the cost adjustment routine. So do not waste time hunting for a colleague who is “doing something wrong”. Look at what automated processes are running instead.
Is This Normal? (Yes, in Small Doses)
An occasional lock message is completely normal in any busy system. Two people posting at the same moment will sometimes collide, one waits a second, retries, and carries on. That is the system working as designed.
It becomes a problem when it is frequent, when the wait is long (many seconds or a minute), or when it blocks a core daily task like posting sales. That level of locking points to a specific cause you can fix, which is what the rest of this guide is about.
Quick Fix for Users
If you hit this once in a while, the fix is simple:
- Wait a few seconds and click retry, or try the action again. The other process usually finishes quickly and releases the lock.
- Do not click post repeatedly. Hammering the button just queues more attempts. Wait, then try once.
- If you are posting a very large document (say 40+ lines), give it a moment; big postings hold locks a little longer.
- If it keeps failing, note the table name in the message (for example G/L Entry, Sales Line, Item Ledger Entry) and tell your admin. That table name is the biggest clue to the cause.
💡 Tip: The exact table named in the error matters. A lock on Item Ledger Entry often points to cost adjustment, while a lock on G/L Entry points to heavy posting. Always pass the table name to whoever investigates.
Why It Keeps Happening (Real Causes)
When the error is frequent, it is almost always one of these:
| Cause | What Happens |
|---|---|
| Automatic Cost Adjustment = Always | This setting runs cost adjustment during every posting, locking item and ledger tables. A very common cause of frequent G/L Entry and Item Ledger Entry locks. |
| Long-running postings | Very large documents or batch posts hold locks longer, so others waiting to post collide with them. |
| Heavy reports during work hours | A big report or query reading the same tables at peak time can block posting, and posting can block the report. |
| Inefficient custom code | Extensions that lock tables early, do too much in one transaction, or Commit in loops hold locks far too long. |
| Deadlocks | Two processes each wait for a table the other holds. SQL Server ends one so the other can finish, and the ended one shows this error. |
| Object lock (rare) | On-premises only: a table object left checked as Locked after development work. Different from a record lock, but can block use. |
Fixes for Admins and Partners
Here is how to tackle each cause. Some are settings you can change; others need care and testing.
Review Automatic Cost Adjustment. Search Inventory Setup and check the Automatic Cost Adjustment field. If it is set to Always and you are getting frequent locks, consider changing it to Never and instead running the Adjust Cost, Item Entries batch job on a schedule, off-peak (for example nightly). This is one of the single most effective fixes for constant posting locks. Test the change in a sandbox first, and confirm your costing expectations with your accountant or partner.
Move heavy reports and batch jobs off-peak. Reschedule large reports, cost adjustment, and any heavy job queue entries to run outside busy posting hours. If a report must run in the day, see whether it can read with a lower isolation level so it does not block posting.
Review custom code. If a specific extension is involved, a developer should check it for long transactions, locking tables too early, or Commit inside loops. The goal is to lock late, do the minimum, and release fast. Good performance is the same thing as fewer deadlocks.
Keep the system fast generally. Slow queries hold locks longer, so general performance tuning reduces locking as a side effect. Our guide on Business Central slow performance fixes covers this in detail.
⚠️ Do not just increase the lock timeout to hide the problem. Making Business Central wait longer for locks only means users wait longer before the same error appears. Fix the cause (cost adjustment, job timing, or code), do not mask the symptom.
How to Find Who or What Is Locking
To fix repeated locks, you often need to know exactly what is holding them. There are a few ways.
On Business Central online (SaaS), the best tool is Database Lock Timeout telemetry in Application Insights. When a lock times out, Business Central emits a Database lock timed out event with the AL object, the code, and the extension involved, followed by lock snapshot events showing which SQL session held the lock. This tells you precisely what caused it, which is far better than guessing.
On on-premises, you can also check active sessions and, for the rare object-lock case, confirm whether a table object is marked as Locked and compile or unlock it.
For a step-by-step on identifying the specific session or user holding a lock, see our companion guide: How to Find Which User is Locking a Table.
How to Prevent Locks
A few habits keep locking to a minimum:
- Schedule heavy work off-peak. Cost adjustment, big reports, and batch jobs should run when few users are posting.
- Set Automatic Cost Adjustment thoughtfully. Many businesses run it as a scheduled job rather than Always.
- Post in sensible sizes. Extremely large single postings hold locks longer; where practical, break very large batches up.
- Write efficient extensions. Lock late, keep transactions short, avoid Commit in loops, and access tables in a consistent order to avoid deadlocks.
- Keep the system tuned. Faster queries mean shorter locks. Regular performance care pays off here.
FAQ, Table Locked by Another User
What does “a record in the table was locked by another user” mean?
It means another process was changing the same data and held a lock, and your action waited too long for that lock to release, so it timed out. Business Central stops your action safely. No data is lost; you simply retry.
Is the table lock error a bug?
No. Locks are how the database protects data integrity while records are being written. An occasional lock is normal. Frequent locks point to a fixable cause like cost adjustment, job timing, or code.
Why do I get it constantly on the G/L Entry table?
Often because Automatic Cost Adjustment is set to Always, so cost adjustment runs and locks tables during every posting. Consider setting it to Never and running the Adjust Cost, Item Entries job on an off-peak schedule (test first, and confirm with your accountant).
Is it always another person causing it?
No. The “another user” is often a background process, a scheduled report, or the cost adjustment routine, not a colleague. Check automated processes before hunting for a person.
How do I find out what is holding the lock?
On SaaS, use Database Lock Timeout telemetry in Application Insights, which names the object, code, extension, and SQL session. On-premises, check active sessions. See our companion guide on finding which user is locking a table.
Should I just increase the lock timeout?
No. That only makes users wait longer before the same error appears. Fix the underlying cause instead: cost adjustment settings, job scheduling, or inefficient code.
What is a deadlock versus a lock timeout?
A lock timeout is your action giving up after waiting too long for a lock. A deadlock is two processes each waiting for something the other holds; SQL Server ends one of them so the other can proceed. Both surface as this same error message.
Final Thoughts
The “table was locked by another user” message sounds alarming but is usually harmless: the database protecting your data while something else finishes. If it is occasional, wait and retry. If it is constant, it is a signal worth acting on, and the causes are well known: Automatic Cost Adjustment set to Always, heavy jobs running at peak, oversized postings, or inefficient custom code.
Note the table named in the error, use telemetry to see what holds the lock, fix the cause rather than masking it, and schedule heavy work off-peak. Do that, and a daily frustration becomes a rare, harmless blip.
Stay tuned to NavisionPlanet for more practical Business Central troubleshooting guides drawn from real project experience.
Note: Costing and posting settings affect financial results. Test any change to Automatic Cost Adjustment in a sandbox and confirm the impact with your accountant or partner before applying it in production.
Jubel
Microsoft Certified Business Central Consultant
Jubel is a Microsoft Dynamics 365 Business Central, NAV, and LS Central expert with 18+ years of experience, and the founder of Navision Planet (since 2009). He shares practical, real-world guidance on Business Central, LS Central, SQL, and the wider Microsoft stack, drawn from work across 150+ organizations.
📖 Related guides on Navision Planet:
→ How to Find Which User is Locking a Table
→ Business Central Running Slow? Causes and Fixes
→ Business Central Known Issues List
→ Business Central On-Premises Installation Fatal Error Fixes
