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—for example, to add an attribute column, to change the rules in a topology, to 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.

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.

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.

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 of 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 at least have 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 Jet Engine to open and modify the .ldb file to control access to the .mdb file.

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.

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.