Infor LN: "Record is locked by another user" error
Record is locked by another user error in Infor LN
Also searched as
- LN session shows record locked by user
- how to unlock a locked record in Infor LN
- Baan ERP record locked by another user fix
- LN Active Sessions locked record
Short answer
This error means another LN session, interactive or batch, is holding an update lock on the same table row you are trying to change. Find the locking user or session in Active Sessions, confirm it is stale rather than genuinely running, and either wait or terminate it before you retry.
Applies to: Infor LN 10.x, LN FP, Baan IV/V (LN/DAL runtime record locking)
Fix a locked record in LN
- 1Note the exact table and record identifier shown in the error message
- 2Open Tools - Active Sessions as an authorized user
- 3Filter by company or user to find who is running a session against that table
- 4Check whether the session is genuinely active (running a long job) or stalled (idle, disconnected client)
- 5If stalled, select the session and use Terminate Session, or ask the DBA to kill the underlying database connection
- 6Confirm the lock is released by re-querying the record from a browse session
- 7Retry the original transaction
- 8If the same record locks repeatedly, check for a stuck batch job or integration process polling that table
- 9Log a case with your LN partner if a report or BOD process is holding locks longer than its normal run time
Why LN locks records
LN runs on the DAL/4GL runtime, and many financial and inventory update sessions take a lock on a record for the duration of an open transaction rather than only at the moment of save. That protects totals and balances from being corrupted by two simultaneous writers, but it means a slow or stalled session can block everyone else who touches the same row.
Interactive sessions, background/batch sessions, and BOD or ION integration processes can all hold this kind of lock, which is why the same error can appear from a user typing in a form or from an automated import running unattended.
Finding the locking session
Active Sessions gives an overview of every connected user and process, including company, session code, and how long it has been running. Filtering by the table or module named in the error narrows the list quickly in a busy multi-company environment.
When Active Sessions is not enough, a DBA can confirm the same thing from the database side by checking blocking sessions directly.
-- SQL Server: find blocking sessions
SELECT blocking_session_id, session_id, wait_type, wait_time
FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;
Stale vs active locks
A crashed client, a lost terminal services session, or a network drop can leave a lock in place long after the user thinks they closed the screen. These orphan locks look identical in the error message to a legitimately busy session, which is why you check Active Sessions before terminating anything.
Preventing recurring lock conflicts
If the same record locks over and over, the fix is usually process design rather than another terminate command: split long batch runs into smaller scopes, schedule heavy jobs outside business hours, and avoid interactive editing of master data during month-end finalize windows when batch jobs are already touching the same tables.
Common pitfalls
- !Killing a session mid-transaction can leave a record in an inconsistent state - confirm it is stale before terminating
- !Terminating a batch job that is legitimately running (a large MRP or cost rollup) restarts it from scratch
- !One application-level action can hold several database-level locks, so releasing one may not clear the error
- !Repeated locking on the same record usually points to two processes writing the same master data, not a one-off glitch
- !Restarting the LN application server clears all locks but disrupts every connected user, so it is a last resort
How an ERP-grounded AI assistant handles this
ERPray, grounded in your LN environment, can look up which session and user currently hold a lock on a given table or record by querying Active Sessions data through the ERP connection, so a support desk or power user gets an answer to "who has this record locked" in a chat message instead of opening Active Sessions and filtering by company and table by hand.
Frequently asked questions
What causes "Record is locked by another user" in LN?
Another session already has an open update transaction against that exact record. LN's DAL layer enforces this kind of lock so a second writer has to wait or fail with this message rather than overwrite in-progress changes.
Can I just retry until it clears?
Yes for short locks from normal transaction processing - most clear in seconds. If it persists for more than a few minutes, check Active Sessions for the locking session instead of retrying blindly.
Is this the same as a "record has been modified" error?
No. This is a live lock held during an open transaction. The record-modified error fires afterward, when your copy of a record is stale compared to what someone else already saved.
Does terminating a session risk data corruption?
Usually the database rolls back an incomplete transaction cleanly, but terminating a session mid-commit on a financial posting or finalize process can leave partial records. Check with an admin first on those modules.
Related
Infor LN bshell Process Stuck at 100% CPU: How to Diagnose and Fix It
A bshell process pinned at 100% CPU on the Infor LN application server almost always means one session is stuck in a 4GL loop, scanning an unindexed table, or waiting on a database lock. End the session from the Sessions Monitor first, then kill the OS process only if that fails, and check for a blocking database transaction before assuming it is a bug.
Error fixInfor LN Jobs Stuck in Active or Waiting: Fix the Job Daemon
Infor LN background jobs, reports, batch processes and print jobs, get stuck in Active or Waiting status when the job daemon on the enterprise server has stopped or lost its connection, or when a prior job crashed without releasing its status. Restart the job daemon and reset the stuck job's status through the Jobs session, and the queue resumes. A daemon that keeps stopping usually points to a memory, license or database connectivity problem on the server.
Error fixInfor LN Not Authorized to Run This Session: How to Fix It
Infor LN refuses to open a session with a not authorized message when the logged-in user's assigned role does not include that session, or when the session is blocked for the company they are logged into. Grant the session through Common > Authorization Management > Roles, or check the user's role and company context, and the session opens on retry. In most cases this is a permissions configuration issue, not a bug.
Error fixInfor LN Not Authorized to Run This Session: How to Fix It
Infor LN refuses to open a session with a not authorized message when the logged-in user's assigned role does not include that session, or when the session is blocked for the company they are logged into. Grant the session through Common > Authorization Management > Roles, or check the user's role and company context, and the session opens on retry. In most cases this is a permissions configuration issue, not a bug.
Error fixInfor LN: finalize run fails or gets stuck
Finalize sessions such as Cost Price Calculation, Sales Invoicing, and Period-End Statistics run as a broadly locked, largely exclusive batch step, so they most often fail because another user has the module open, a prior finalize run did not close cleanly, or a specific record has bad master data. Read the finalize log for the exact record or reason code, not just the failure message.
Error fixInfor LN DAL Out of Sync After a Custom Field: Cause and Fix
Infor LN throws a DAL, or table, out of sync error, or simply drops a new custom field silently, when a table's dictionary definition is changed but the generated DAL and dependent forms are not regenerated afterward. Running the standard sequence, table compile, DAL generation, then session/form compile, in Tools > Development after every dictionary change resolves it. Skipping any one of the three steps is what causes the mismatch.
AI for ERPAI for Infor LN: Sessions, BODs, and Engineer-to-Order Work
Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.
AI for ERPAI for Legacy Baan IV/V: Capture the Knowledge Before It Walks Out the Door
Use AI to capture knowledge from ageing Baan IV/V systems, document undocumented customisations, and de-risk a future migration to LN or CloudSuite.
Stuck on Infor LN (Baan)?
Talk to engineers who work inside Infor LN (Baan) every week, and who build private AI that answers these questions from your own ERP data.