# Infor LN: "Record is locked by another user" error

> Source: https://netray.co/erp-help/ln-record-locked-by-another-user-fix
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## 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.

## Kind

error

## System

infor-ln

## Erp

Infor LN (Baan)

## Module

Common Data / Session Locking

## Query

Record is locked by another user error in Infor LN

## Alternate Queries

- 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

## Applies To

Infor LN 10.x, LN FP, Baan IV/V (LN/DAL runtime record locking)

## Steps

### Fix a locked record in LN

**Items:**

- Note the exact table and record identifier shown in the error message
- Open Tools - Active Sessions as an authorized user
- Filter by company or user to find who is running a session against that table
- Check whether the session is genuinely active (running a long job) or stalled (idle, disconnected client)
- If stalled, select the session and use Terminate Session, or ask the DBA to kill the underlying database connection
- Confirm the lock is released by re-querying the record from a browse session
- Retry the original transaction
- If the same record locks repeatedly, check for a stuck batch job or integration process polling that table
- Log a case with your LN partner if a report or BOD process is holding locks longer than its normal run time

## Sections

### Why LN locks records

**Body:**

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

**Body:**

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.

**Code:**

- -- 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

**Body:**

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

**Body:**

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.

## 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

## Ai Angle

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.

## Faq

### What causes "Record is locked by another user" in LN?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

infor ln record locked, baan record locked by another user, ln active sessions terminate, ln unlock locked record, infor ln locking error, baan lock conflict fix, ln session stuck locked record, infor ln database blocking session

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
