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 table or feature class is registered as versioned, two additional tables are created in the database: an adds and a deletes table. These two tables track the edits made to the table or feature class. For each dataset that is versioned, a new set of these tables is created. When you register a feature dataset as versioned, an adds and a deletes table is created for each of the feature classes in the feature dataset.

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

Creating additional versions and granting access to them

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 that track the state of the data.

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

Reconciling versions

Reconciling versions pulls down changes from the target version into the version you are editing. At the same time, ArcGIS checks for conflicts between the version you are editing and the target version. This gives you a way to review and resolve any conflicts between 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 effect on geodatabase performance.

To maintain geodatabase performance, the geodatabase 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 geodatabase administrator.

8/21/2013