The 3 a.m. Editing Lock Mystery
A three-person GIS team edits a versioned feature class in an enterprise geodatabase through ArcGIS Pro. A field crew member who was dismissed last week left Pro open on a laptop that is now powered off in a drawer. Since then, the team reports that they can view the feature class but any edit attempt fails immediately with a lock-related error, and no one can reconcile or post. The geodatabase administrator is on leave. The team has a deadline in six hours. They propose to unregister the feature class as versioned, make edits to the base table, then re-register it.
1. Evaluate the proposed workaround of unregistering the feature class as versioned to clear the blockage. What are the risks and what should the team do instead?
Read the worked answer
Unregistering as versioned is a destructive administrative operation, not a lock-clearing tool. It collapses versioned edits into the base table and, depending on the option chosen, can discard or orphan existing versions and their edits. It also breaks the versioning contract for every other editor and consumer, and re-registering does not restore the prior version tree. Doing this to meet a deadline is a high-risk action that should require the DBA, not a field expedient.
The actual symptom - can view, cannot edit, cannot reconcile/post - is consistent with a stale lock or an open edit session held by the disconnected laptop. The correct path is to identify and clear the session: use the geodatabase administration tools to list current sessions/locks, confirm the lock owner matches the dismissed user's machine, and have an administrator remove that session. Because the DBA is on leave, escalate to whoever holds administrative credentials rather than improvising schema changes. If no administrator is reachable, document the blockage and work in a separate, non-versioned staging feature class that can later be loaded, rather than altering the production schema.
2. The team also asks whether they can simply delete the dismissed employee's database login to release the lock. How should you respond?
Read the worked answer
Deleting the login is the wrong instrument and may not release the lock. An active session is tied to a connection; dropping the login does not necessarily terminate the session, and it removes the account needed to audit or trace what that user did. It can also fail if the login owns objects or schema.
The right sequence is: (1) identify the session and its connection, (2) terminate that specific session through the administration tools, (3) then disable - not immediately delete - the login so the account cannot reconnect, preserving audit history. Deleting should follow only after confirming the account owns nothing and after the incident is reviewed. Emphasize that lock clearing is a targeted session operation, while account lifecycle is a separate security decision; conflating them creates both an availability problem and an audit gap.