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 ArcSDE 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 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 locks

ArcGIS will automatically acquire a shared lock on an individual dataset when it is in use, for example, any time 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 will attempt 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 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.

Using 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 all the 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.

Using 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.

Using locks in ArcSDE geodatabases

Users must have appropriate user permissions to the ArcSDE geodatabase to make changes to its schema. See User permissions for information on how to establish and manage permissions in ArcSDE.

Schema locks, both shared and exclusive, apply to individual datasets and related tables in an ArcSDE 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.