We have file geodatabase on a network drive, version 9.2, which locks every time a specific machine starts up ArcMap 10.0 or ArcCatalog 10.0.
This machine isn't actually reading anything from this geodatabase. It is just opening up a blank map document or browsing other directories elsewhere on the network. However, this machine has accessed this geodatabase in the past.
Has anybody ever come across this?
Things we have tried so far to stop this locking:
1 – Opened up enough map documents so that none of the mxd's in the recently opened list in the "File" menu in ArcMap have data from this database.
2 – Disconnected this network drive from the folder connections in ArcCatalog
3 – Deleted the normal templates for ArcCatalog and ArcMap.
4 – Re-started the machine
5 – Deleted the original database and made a new one in the same location.
None of the above worked.
The only thing that works is to remove the connection from this machine to the network share i.e. remove the connection to the "N" drive in MyComputer.
Unfortunately this isn't a feasible solution as the machine needs to have that network share mapped to that drive letter.
Any suggestions on how to prevent the lock?
Best Answer
Viewing the contents of a file geodatabase OR editing its contents using an Esri product, it doesn't matter which, will produce a .LOCK file inside the file GDB's folder on the file system which can be seen via Windows Explorer. It will contain some numbers in its filename, one of which refers to the process ID (PID) of the active process connecting to it. To know which process or application has your FGDB locked, open Task Manager and explore the contents of your GDB folder on the file system using Windows Explorer. Add the PID field to Task Manager and then compare the process IDs in Task Manager to that of the lock file to identify the culprit. The presence of the .LOCK file is essentially an exclusive lock and won't allow you to do much else other than view the FGDB contents until it is gone. Killing those connections can be done by ending the process brutally in Task Manager or gracefully closing an application or stopping a GIS service, if applicable.
Now, if there is no lock file or process holding on to the FGDB, then you probably have a system lock of some sort that hasn't cleared up. Rebooting should resolve that; but if rebooting isn't possible then you'll need to close the FGDB files manually. If you have Windows 7 or Server 2008 R2 or higher, read on:
If you are still having issues with deleting a geodatabase on the file system despite the fact that the .lock files no longer exist, it's possible there is still a process lock on one or more of the files within it. That being said, if you're using Windows Server 2008 / Windows 7 or later you can try one of the following methods:
From the Start menu, type FSMGMT.MSC, then multi-select the files you want from the GUI, then right click them and chose "Close". That method should force close the files that are technically still open due to a process lock.
or
From a batch file, run the following (example is for a file geodatabase) to close a file named a00000225.gdbtable (this filename is just an example):
cd C:\this_server\directory\subdirectory
for /f "skip=4 tokens=1,2*" %%a in ('net files') do if %%b == C:\this_server...\a00000225.gdbtable net file %%a /close
You can modify the command above to loop through all of the files in the file geodatabase to close them all rather than specify them individually, which would be tedious since there are so many.
From the command prompt, type NET FILES to see what the bold text above should contain.
Remember that double percent characters are required for batch files (in other words, %% rather than %) but single percent characters are used when running the command outside of a batch script.