JD Edwards: record is being used by another user (record reservation)
JD Edwards record is being used by another user, cannot update
Also searched as
- JDE record reservation error
- This record is being edited by another user JDE
- F00165 record lock stuck
- clear locked record JD Edwards
Short answer
EnterpriseOne places a soft record reservation lock when a user opens a record for edit, tracked in the F00165 table, and releases it when the user saves, cancels, or the session ends cleanly. A stuck lock almost always means a session died abnormally (browser crash, network drop, kiosk timeout) without triggering the release, and it must be cleared by an admin, not by the original user retrying.
Applies to: JD Edwards EnterpriseOne 9.1, 9.2, HTML client and Fat Client
Find and clear a stuck record lock
- 1Ask the user for the exact application, form, and key record they were editing (business unit, order number, item number, etc).
- 2As a system admin, open Work With Server Jobs or query F00165 (Record Reservation table) via a SQL client or UTB to find the lock row matching that key.
- 3Confirm the locking user's session is actually gone - check Work With User/Group Job Status (P0INFO or the health check pages) for an active or orphaned session under that user ID.
- 4If the session is truly gone, delete or clear the matching F00165 row for that key value, or use the delivered clear-locks utility if your CNC team has one scripted.
- 5If the session shows as still active, contact that user first rather than force-clearing, since force-clearing while they are mid-edit can cause a lost-update conflict.
- 6For recurring stuck locks on the same application, check for abnormal client terminations (kiosk mode timeouts, VPN drops) rather than treating each incident as isolated.
- 7After clearing, have the original user retry the update; the lock should now acquire normally.
How record reservation actually works
EnterpriseOne's record reservation is an application-level lock, not a database row lock. When a user opens a record in update mode, the client calls a reservation check against F00165, keyed by table name, key value, and environment. If no row exists, one is inserted for that user; if one already exists for someone else, the second user gets the 'being used by another user' message.
This is deliberately optimistic-but-visible: it prevents two people editing the same sales order header at once, but it is enforced in application logic (business functions like B0000018) rather than by the underlying database, so a crashed client session can leave an orphaned F00165 row behind.
Why locks get stuck
The release only fires when the application executes its normal exit or save path. A browser tab closed forcibly, a network timeout mid-session, a killed Java process on the HTML server, or a Fat Client crash all skip that cleanup step, leaving the F00165 row in place indefinitely.
JDE does have session-timeout based cleanup in some configurations, but it is not guaranteed to run promptly, especially for interactive sessions that were never properly logged out server-side.
Querying and clearing F00165 directly
F00165 holds columns for the reserving user (RVUSER), the table and key being locked, and environment/reservation type. A targeted SQL select against F00165 by table name and key is the fastest way to confirm a specific lock, faster than paging through generic admin screens for a high-volume table like F4211 (sales order detail).
Deleting the row directly via SQL is possible but should go through your CNC/Basis team's approved method, since some sites wrap this in a supported utility or P00165 application rather than raw SQL deletes against production.
SELECT RVUSER, RVFILE, RVKEY, RVENV FROM PRODDTA.F00165 WHERE RVFILE = 'F4211' AND RVKEY LIKE '%4500123%'
Common pitfalls
- !Force-clearing a lock without confirming the original session is actually dead - this can cause silent data loss if that user saves seconds later.
- !Treating repeated locks on the same app as a JDE bug when the real cause is an unstable client network or a kiosk device that never logs out cleanly.
- !Searching F00165 by user ID alone when multiple stale rows exist - always match on the specific table and key to avoid clearing the wrong record's lock.
- !Not checking whether the lock is actually a database-level lock (blocking session in the RDBMS) instead of an F00165 application lock - the fix and diagnosis differ completely.
- !Assuming a server restart will clean up all stale F00165 rows - it does not; these are data rows, not in-memory session state.
How an ERP-grounded AI assistant handles this
ERPray can be asked in plain language 'who has sales order 4500123 locked and since when' and answer directly from F00165 plus session status, instead of an admin hand-writing SQL every time a user reports the message. For SyteLine/CSI environments the equivalent lock-diagnosis pattern is handled by SyteRay's grounded queries against IDO session state.
Frequently asked questions
Is F00165 a database lock or a JDE application lock?
It is an application-level lock enforced by EnterpriseOne business functions, tracked as ordinary rows in the F00165 table. The underlying database does not see it as a lock at all, which is why deleting the row is enough to clear it.
Can I just log the stuck user out to fix it?
Usually not by itself - if their client session already died, there is nothing to log out server-side, and the F00165 row will remain until explicitly cleared. Check Work With User/Group Job Status first to see if an active session even exists.
Does this happen on both Fat Client and HTML client?
Yes, both go through the same record reservation business functions server-side, so an unclean exit from either client type can leave an orphaned F00165 row.
Is there a delivered EnterpriseOne screen to manage locks, or only SQL?
Some sites use P00165 or CNC utilities delivered for reservation management; availability depends on your tools release and what your CNC team has configured. Direct SQL is a common fallback where no such screen is enabled.
Related
JDE UBE failed (status E): how to read jde.log and jdedebug.log
A UBE (batch report/program) that ends with status E in Work With Submitted Jobs tells you almost nothing on its own. The real error is in jde.log on the enterprise server, in the job's own PDF/log subdirectory (jdedebug.log if you turned on debug), and in the work directory for that job number under PrintQueue or the OS temp path.
Error fixJD Edwards business function (BSFN) errors: how to diagnose them
A BSFN error in EnterpriseOne means either the compiled function was not found for the current package build, or the function ran and threw an internal exception (often a null business view row, an unhandled C runtime error, or a failed table I/O). The fix path is different for each, so the first step is always determining which one you are facing from jde.log.
How-toHow to set up JD Edwards Orchestrator (step by step)
An EnterpriseOne orchestration chains one or more requests (form requests that drive an interactive application, or service requests that call a BSFN, business service, or SQL) plus optional rules and notifications, then exposes the whole thing as a callable REST endpoint via the AIS (Application Interface Services) server. The setup work happens in Orchestrator Studio, not the Fat Client.
How-toHow to set data selection and processing options in JD Edwards
Data selection controls which rows a UBE's underlying business view reads (a filter, stored per version in F9210/F9211), while processing options control how the program behaves once it has that data (a settings template stored per version in F983051/F983052). They are configured from the same Version Detail screen but are separate, unrelated mechanisms that new users routinely confuse.
Error fixJDE package build failed: how to find the real cause
A package build (Full or Update) that ends in a failed or errored status on the deployment server does not explain itself in the Package Build Workbench screen. The real diagnostic detail is in the package's own log subdirectory on the deployment server, which holds a build log, a table conversion log, and per-object compile logs that pinpoint the actual failure.
How-toJD Edwards table conversion: how it works and how to run one
Table conversion (TC) is the EnterpriseOne mechanism that updates a table's physical structure and converts its existing data whenever a table's definition changes in Object Librarian, most commonly running automatically as part of a package build. Simple field additions or size changes convert automatically; more complex changes such as splitting a field or transforming values need a custom conversion routine attached to the table object.
AI for ERPAI for JD Edwards EnterpriseOne, Built on Orchestrator and AIS
Add AI to JD Edwards E1 9.2 using Orchestrator, AIS, and BSSV rather than screen-scraping. Ground a private LLM on F4211, F4111, and F0411 data.
Stuck on JD Edwards EnterpriseOne?
Talk to engineers who work inside JD Edwards EnterpriseOne every week, and who build private AI that answers these questions from your own ERP data.