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:
- The users who need to have access to the data and versions have the proper permissions. For example, if users other than the version owner need to access a version, the permission on the version must be set to either protected (other users can view the version) or public (other users can view and update the version).
- All users who reconcile edited versioned data know how conflicts between versions should be defined: by row or by column.
- You know which user will make decisions about which version of edits to keep when resolving conflicts.
- Each editor knows which version he or she should use for editing.
- Decide whether you are going to use replication as part of your versioning workflow.
- Decide whether you are going to use archiving as part of your versioning workflow.
- You have a set schedule for compressing the geodatabase.
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:
- Public—Any user may view the version. Any user who has been granted read/write (UPDATE, INSERT, and DELETE or read/write) permissions on datasets can modify those datasets.
- Protected—Any user may view the version, but only the owner or the ArcSDE administrator may edit datasets to which he or she has read/write permission.
- Private—Only the owner or the ArcSDE administrator may view the version and modify versioned data.
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.