File geodatabases and locking
File geodatabases and locking
|
| Release 9.3 |
   |
If you are the sole user working with a dataset in a file geodatabase and are accessing it via one process only, you are able to freely edit or modify its properties. You are also able to delete, compress, or uncompress the dataset.
However, if another process is already accessing the data, whether it be a process on your computer or another user's, ArcGIS will prevent you from performing any of these operations until the other process has terminated. For example, if you attempt to delete a feature class called Roads with ArcCatalog while it is displayed in ArcMap, you'll get the message:
Failed to delete selected object(s)
Cannot acquire a schema lock because of an existing lock.[
The table Roads has the following schema locks:
Computer: <name of computer>, Process <process ID> (ArcMap)]
ArcMap is accessing the Roads dataset and has locked it, preventing ArcCatalog from deleting it. If you then remove the layer from ArcMap and try again, you will be able to delete the feature class, providing no other processes are accessing the data.
When a process accesses a dataset in a file geodatabase, it locks it to prevent inconsistent or unexpected results for those displaying or querying the data. While a dataset is being displayed or queried, the lock ensures the data cannot change in the process.
To lock a dataset, a process places a *.lock file in the file geodatabase folder, providing the user of the process has write access to the folder containing the data. When the process no longer accesses the data or terminates, the lock files associated with it are automatically deleted. In some cases however, such as when a process ends prematurely, lock files may be left behind in the geodatabase folder. These lock files are eventually removed by ArcGIS in future sessions as new locks are taken. They are also removed whenever you run the GP Compact tool or Copy/Paste a file geodatabase with ArcCatalog. In the meantime, these lock files do not continue to lock data.
Accessing a dataset not only locks that dataset, but also locks additional related datasets as follows:
- A process accessing a feature class within a feature dataset locks all of the feature classes in the feature dataset.
- Locks apply to both sides of a relationship class. That is, if two stand-alone feature classes are related via a relationship class and a process accesses one of them, both feature classes lock.
As of ArcGIS 9.3 service pack 1, most file geodatabase lock error messages report the name of the computer and identify the process on that computer that is accessing the data. Information about the process can include the process ID number or Unknown if ArcGIS is unable to determine the process ID. This information helps you find the process, whether it be on your computer or another user's, so that you can either terminate it or wait for it to end on its own.
If you are ever prevented from editing a dataset or its properties, or from deleting, compressing or uncompressing and get a lock error message, it's because one of the following is happening
- You are accessing the data with two or more processes simultaneously, such as ArcMap and ArcCatalog, or ArcCatalog and python. Close one of the applications so you can perform the operation you want.
- The data is a resource in an active map service or other type of service. When a service starts, it locks the data. Each instance of the service places its own lock on the dataset. You can clear the locks by stopping the service with ArcGIS Server Manager or ArcCatalog.
- The data is being accessed by one or more processes on another computer. Wait for the processes to terminate or have the user(s) terminate any process accessing the data.
As a last resort, you can clear all active locks by restarting the computer containing the file geodatabase. However, before you do this, make sure nobody is accessing the data otherwise their work will not be saved.
NOTE: Just like when you work with other types of files, it's a good idea to regularly back up your file geodatabase in case something goes wrong.