# JD Edwards: record is being used by another user (record reservation) > Source: https://netray.co/erp-help/jde-record-locked-cannot-update > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System jd-edwards ## Erp JD Edwards EnterpriseOne ## Module Interactive Applications / Row Security ## Query JD Edwards record is being used by another user, cannot update ## Alternate Queries - JDE record reservation error - This record is being edited by another user JDE - F00165 record lock stuck - clear locked record JD Edwards ## Applies To JD Edwards EnterpriseOne 9.1, 9.2, HTML client and Fat Client ## Steps ### Find and clear a stuck record lock **Items:** - Ask the user for the exact application, form, and key record they were editing (business unit, order number, item number, etc). - As 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. - Confirm 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. - If 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. - If 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. - For recurring stuck locks on the same application, check for abnormal client terminations (kiosk mode timeouts, VPN drops) rather than treating each incident as isolated. - After clearing, have the original user retry the update; the lock should now acquire normally. ## Sections ### How record reservation actually works **Body:** 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 **Body:** 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 **Body:** 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. **Code:** - SELECT RVUSER, RVFILE, RVKEY, RVENV FROM PRODDTA.F00165 WHERE RVFILE = 'F4211' AND RVKEY LIKE '%4500123%' ## 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. ## Ai Angle 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. ## Faq ### Is F00165 a database lock or a JDE application lock? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms JDE record being used by another user, F00165 record reservation, clear stuck JDE lock, JD Edwards record locked error, EnterpriseOne record reservation table, JDE cannot update record in use, P00165 record lock, JDE orphaned session lock --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json