Geodatabase version administration

A versioned geodatabase contains additional tables and records that are not present in a nonversioned geodatabase. These additional tables and records facilitate concurrent editing over long periods of time. Without versioning, editors would lock data and prevent other users from editing or even viewing the data. Using this functionality requires planning and administration.

Individual users register their data as versioned to allow versioned editing. Individual users can also create additional versions of the geodatabase. You must plan ahead to be sure of the following:

Registering data as versioned

When a dataset is registered as versioned, two additional tables are created in the database: an adds and a deletes table. These two tables are associated with the dataset that is registered as versioned and track the edits made to the dataset. For each dataset that is versioned, a new set of these tables is created.

To register data as versioned, you must be the data owner. See Registering data as versioned for instructions.

Creating additional versions and granting permissions

All geodatabases have at least one version: the DEFAULT version, which exists when the geodatabase is created. Any user can create additional versions from existing versions. These new versions are used to group changes made to the data.

Creating new versions does not make a copy of the geodatabase. No matter how many geodatabase versions you have, each table and feature class is stored once in the database. The different versions of the geodatabase are tracked in the VERSIONS system table and associated with the records in the adds and deletes tables, as well as with various system tables.

When a new version is created, the owner of the version determines what sort of access to the version is allowed. Possible permissions are as follows:

Reconciling versions

Once you have finished editing a version, you can merge the changes into any version that is the ancestor of that version, such as the parent or DEFAULT version.

Reconciling versions also allows ArcGIS to check for conflicts between the version you are editing and one of its ancestor versions. This gives you a way to review and resolve any conflicts in edits that have been made to the data by different editors. See Reconciling a version for instructions.

Posting changes to a parent version

Posting changes from your reconciled version to a target version merges the changes into the target version. The versions are now identical.

See Posting changes for instructions.

Compressing the geodatabase

As a geodatabase is edited over time, the adds and deletes tables increase in size. The larger the tables, the more data ArcGIS must process every time you display or query a version. If the adds and deletes tables get very large, this can have a negative affect on geodatabase performance.

To maintain geodatabase performance, the ArcSDE administrator must periodically compress the geodatabase to remove edits not referenced by a version and compress common edits to all versions back to the business table. Geodatabase compression must be done by the ArcSDE administrator.