Available with Standard or Advanced license.
Versioning allows multiple editors to alter the same data in an enterprise or workgroup geodatabase without applying locks or duplicating data. Versioning accomplishes this by storing edits in side tables called delta tables.
To edit feature classes that participate in a topology, network dataset, or geometric network, or to edit a parcel fabric, you must register the data as versioned. This is because when you edit a feature in a network, topology, parcel fabric, not all the features lock, which means other editors can edit another part of the network, topology, or parcel fabric in a way that conflicts with your edits.
You always access an enterprise or workgroup geodatabase through a version. When you connect, you specify the version to which you will connect. By default, you connect to the Default version.
What is a version?
A version is a sort of view of the geodatabase that compartmentalizes edits. Versions allow you and all other users connected to the same version to see your changes. Clients connected to other versions do not see your changes until you reconcile and post them to an ancestor version.
The Default version
The Default version is the root version and, therefore, the ancestor of all other versions.
Unlike other versions, the Default version always exists and cannot be deleted. In most workflow strategies, it is the published version of the geodatabase, representing the current state of the system being modeled. You maintain and update the Default version over time by posting changes to it from other versions. You can also edit the Default version directly, just like any other version.
Creating other versions
You create a version by creating children or branches from any existing version. You create the first version by making a child version of the Default version. When the new version is created, it is identical to the Default version. Over time, the versions diverge as changes are made to the Default version and the new version.
A geodatabase can have many versions. The following is the Version Manager dialog box, which is accessed through ArcGIS Desktop. This example shows the tree view of the dialog box, depicting the Default version and four other versions, and how the versions are related. The Cases and Base versions are children of the Default version, and the Case1 and Case2 versions are children of the Cases version.
Creating a version gives you the impression that you are creating a copy of the entire geodatabase, but you are not. Regardless of how many versions you have, each table and feature class is stored only once in the database. ArcGIS leaves each feature class or table in its original format but records any changes in tables referred to as the delta tables.
Versions can be edited simultaneously by multiple users.
How versions and versioned edits work
Before you can begin performing versioned edits on the data in any version, the datasets must be registered as versioned.
When you register a dataset (a feature class, feature dataset, or table) as versioned, two delta tables are created: the A (or adds) table, which records insertions and updates, and the D (or deletes) table, which stores deletions. Each time you update or delete a record in the dataset, rows are added to one or both of these tables. A versioned dataset, therefore, consists of the original table (referred to as the base or business table) plus any changes in the delta tables. The geodatabase keeps track of which version you were connected to when you made the edits that populated the delta tables. When you query or display a dataset in a version, ArcGIS assembles the relevant rows from the original table and the delta tables to present a seamless view of the data for that version.
All edits to the feature class or table are recorded in the same delta tables, regardless of the version from which the edits were made. This means that any one version references only a subset of rows from the three tables. So how does ArcGIS keep track of which rows in the delta tables belong to which version?
Each row in the A and D tables is marked with an integer identifier called a state ID that references when the row is added to the table. Every time you edit a version, a new state is created and a new row is added to one or both of the delta tables. States can be thought of as being part of a tree structure where each branch records how a version evolves. A sequence of states recording a series of changes from the base table to the current state of a version is called a lineage. When you display or query a version, ArcGIS queries the lineage of a version to get the state IDs, then retrieves the correct records from the A and D tables.
As a geodatabase is edited over time, delta tables increase in size and the number of states increases. The larger the tables and the more states, the more data ArcGIS must process every time you display or query a version. To maintain database performance, the geodatabase administrator must periodically run the Compress command to remove unused data
The option to move edits to base
If you specify the option to move edits to base when you register your data as versioned, changes are recorded in the delta tables. However, when you edit the Default version and save your edits, the changes move from the delta tables to the base table—they do not remain in the delta tables. Note that this is only true when editing the Default version. Edits made to decendent versions are not immediately moved to the base table.
The option to move edits to the base table is useful if the following is true:
- The modifications you are making will take only a few minutes to complete.
- The data does not participate in a network or topology.
- You are connecting to a versioned geodatabase using a third-party application.
Third-party applications are generally set up to query only the base table—they can't access the delta tables. If you use versioning and don't choose to move the edits to the base table, these applications will not incorporate edits made in other versions that have not been reconciled and posted to the Default version. Be aware that as you are editing versions other than the Default, changes are recorded in the same delta tables. When you save, the changes remain in the delta tables. However, when you merge changes into the Default version, changes move from the delta tables to the base tables. Merging changes into versions other than the Default keeps changes in the delta tables, just as if you had not specified to move edits to base.
Permissions and version edits
The owner of the version (the person who creates it) can set who can access the version. Access permission options are as follows:
- Private: Only the version owner can view and edit the datasets in that version.
- Protected: Any user can view the datasets in the version, but only the owner can edit them.
- Public: Any user can view and edit the datasets, provided he or she has been granted permission on the datasets.
Version access is set when the version is created, but it can also be changed on the Version Manager dialog box. See Creating versions and setting access permissions and Version properties for more information.
To edit, connect to a specific geodatabase version from ArcMap and add data that has been registered as versioned to the map.
By default, all edit sessions in ArcMap are versioned edit sessions. Therefore, if you have versioned data in your map, you can start editing as soon as you open an edit session. To open an edit session, click Start Editing on the Editor drop-down list of the Editor toolbar.
Edits made to each version apply only to that version. The exception is schema changes. When you change the schema in a version—for example, add a new field to a table—the change applies to all other versions. Only data owners can alter the schema of a dataset.
When you are done editing, reconcile your changes with and post them to an ancestor version.
Reconcile and post changes
Reconciling and posting operations integrate your changes into any version that is an ancestor of the version you are working in, such as the parent or Default version. When you reconcile, the changes in the version you are editing are compared with the version into which you want to merge them.
When you modify data in a version, no locks are applied to the data. Two editors working on the same data, either in the same version or a different version, can produce conflicts. A conflict occurs when a row differs in the two versions being compared. The reconciliation process shows you each conflict and allows you to choose which representation of the row to preserve.
In practice, editing conflicts should be rare because the volume of edits is small compared to the amount of geographic data involved. In correctly designed workflows, the cost of reconciling conflicts is minor when compared to the savings from not having to lock or check out features for the duration of the transaction.
Once you finish reconciling, you can post the changes. This applies the modifications you made into the other version. If you no longer need the version you posted from, you can delete it. Alternatively, you can edit it further and reconcile and post changes again.
Versions: An example
To illustrate how versions can be used, follow this scenario from a municipal water utility. The water utility company has a geodatabase of features representing the current state of all the water pipes, valves, pumps, and other components of the water system. The utility company needs to add a new line extension to the water system.
An editor creates a new version from the Default version called Extension project, which is to contain the design of the new extension. However, the utility staff are unsure whether to go with a 16-inch or a 24-inch pipe design for the new extension. So, from the Extension project version, they create a version to study the 16-inch design and another to study the 24-inch design.
Staff eventually decide the 24-inch pipe will serve projected water demand for 12 more years and that the greater initial construction cost is justified. The 24-inch design is approved, checked for accuracy, and posted to the Extension project version.
A few months later, the construction of the new line extension is completed. To update the published version of the geodatabase, the Extension project version is reviewed for accuracy, reconciled, and posted to the Default version.
