Schema locking

Note:

In most cases, ArcGIS automatically applies and releases shared locks and exclusive locks on datasets in the geodatabase to help you manage your changes without causing conflicts with other users. The one exception to this rule is when unselecting a geodatabase in ArcCatalog; the folder containing the geodatabase must be manually refreshed to release the lock on the geodatabase. This section describes how these schema locks work.

In workgroup or enterprise geodatabases, more than one user can be reading and editing the same data at the same time. To be able to work with data in a geodatabase for applications such as ArcMap, the application must work on the principle that the geodatabase schema remains fixed and is not changing at any time that you are working with the geodatabase contents. For example, while adding a feature class from a geodatabase to your map, its schema cannot be altered by you or another user. Once you have removed the feature class from your map or closed the map document, and no other users are querying or editing that feature class, its schema can be altered.

An overview of schema locking

Geodatabases and their datasets are rarely static. Most datasets are edited and updated through time. Occasionally, new datasets are added and existing ones removed for a multitude of reasons. In addition, schema changes are made to existing datasets—to add an attribute column, change the rules in a topology, add cartographic representations, and so forth.

If you are working with a single-user geodatabase, these changes are easy to make, and you do not have to think about how your work might impact others. However, if other users are accessing and using the same geodatabase in which you want to make changes, you'll need to establish some workflows for making schema changes. For example, to make changes without impacting other users, you might schedule your schema work to be performed when all other users are off the system.

ArcGIS provides some automated schema locking mechanisms to help you manage your geodatabase changes. It's useful to consider these as you plan your work.

Shared schema locks

ArcGIS automatically acquires a shared lock on an individual dataset when it is in use, for example, anytime a user is editing or querying the contents of a feature class or table. This mechanism is used so other users cannot make changes to the underlying dataset and its schema while it is in use.

Any number of shared locks can be established on a single feature class or table at any given time. When you use ArcGIS to modify your geodatabase schema—for example, to add a field or alter rules—ArcGIS attempts to establish an exclusive lock on the data being altered. However, if a shared lock exists on that dataset, an exclusive lock cannot be established.

Exclusive schema locks

An exclusive lock is used to lock a dataset in the geodatabase from use by others to make necessary changes to it; for example, to alter the dataset's schema. Once a user with proper permissions starts to make changes to a dataset in the geodatabase, ArcGIS will automatically establish an exclusive lock on the individual attribute table, feature class table, raster table, or other dataset.

If a user wants to make changes to a geodatabase schema, the specific datasets with which he or she is working must not be in use by others. In other words, to make changes to a dataset, a shared lock must not exist on that dataset.

Locks in personal geodatabases

In personal geodatabases, all locks apply to all the contents in the whole geodatabase. Once an exclusive lock or a shared lock is acquired on an item in a personal geodatabase, that lock applies to the entire geodatabase. This means that only one editor can edit a personal geodatabase at a time.

Any user that has proper read/write access to the Microsoft Access database (.mdb) file that holds the personal geodatabase can edit and change its schema contents.

When accessing a personal geodatabase stored on a network drive or through UNC paths, make sure that all users have at least write access to the folder containing the personal geodatabase. If all users do not have write access, only one user will be able to open the personal geodatabase. Subsequent attempts to open the personal geodatabase will result in a schema locking error due to the inability of the Microsoft Jet Database Engine to open and modify the .ldb file to control access to the .mdb file.

Locks in file geodatabases

Users must have read/write access to the file geodatabase folder to make changes to its schema.

Schema locks, both shared and exclusive, apply to individual datasets and related tables in a file geodatabase. For example:

• If you acquire a lock on a feature class within a feature dataset, the lock applies to the entire feature dataset and its contents.
• Locks also apply to both sides of a relationship class. For example, if two stand-alone feature classes are related via a relationship class and you acquire an exclusive or shared lock on one of them, the lock also applies to the other.

Tip:

When you copy or move a file geodatabase in Windows Explorer, locks may be held by others on files within the geodatabase. To avoid this, use ArcGIS for Desktop to copy or move file geodatabases.

Locks in workgroup or enterprise geodatabases

Users must own a dataset to make changes to its schema and have the appropriate privileges granted to them to edit other user's data. See What are user privileges for information on different types of privileges needed to edit data.

Schema locks, both shared and exclusive, are applied to individual datasets and related tables. For example:

• If you acquire a lock on a feature class within a feature dataset, the lock applies to the entire feature dataset and its contents.
• Locks also apply to both sides of a relationship class. For example, if two stand-alone feature classes are related via a relationship class and you acquire an exclusive or shared lock on one of them, the lock also applies to the other.