Available with Standard or Advanced license.
Versioning allows multiple users to edit the same data in an enterprise geodatabase at the same time without applying locks or duplicating data. A version represents a snapshot in time of the entire geodatabase and contains all the datasets in the geodatabase.
Versions are not separate copies of the geodatabase. Instead, versions and the transactions that take place within them are tracked in system tables. This isolates an editor's work across multiple edit sessions, allowing users to edit without locking features in the production version or immediately impacting others, and without having to make copies of the data.
Workflows vary greatly among organizations. They often progress in discrete stages, with each stage requiring the allocation of a different set of resources and business rules. Typically, each stage in the overall process represents a discrete unit of work, such as a work order. To manage each work order, you can create a separate, isolated version and modify it. Once you're satisfied the work is complete, you can integrate the changes into the published version of the database. Working with versions this way gives you the ability to accommodate the most basic of workflow processes as well as the most complex.
Register data as versioned
Register data as versioned to allow multiple users to edit the same data without applying locks. When you register your data as versioned, two delta tables are created to track insert, update, and delete operations performed on the data. Therefore, a versioned dataset consists of the original table (called the business or base table) plus any changes stored in the delta tables.
You always access an enterprise geodatabase through a version. After you connect to an enterprise geodatabase, you can specify the version to which you will connect in the Geodatabase Connection Properties dialog box. By default, you connect to the Default version.
Every enterprise geodatabase has a version named Default; therefore, versioning is always enabled for the geodatabase. It is a fundamental part of how enterprise geodatabases operate and does not need to be installed or configured independently.
Unlike other versions, the Default version always exists and cannot be deleted. In most workflow strategies, it is the published version of the database, 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.
The Default version is the root version and, therefore, the ancestor of all other versions.
Create 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 this version is created, it is identical to the Default version. Over time, the versions diverge as changes are made to the Default version and to the new version.
A geodatabase can have many versions. In ArcGIS Pro, you can use the Version Manager to create, modify, and delete versions in an enterprise geodatabase.
Creating a version gives you the false impression that you are creating a copy of the entire geodatabase. This is because each version has all the tables and feature classes in the geodatabase. As you edit a feature class or table in a version, it is no longer the same as the feature class or table in the parent version, so it appear s as if you are storing the feature class or table in each version. However, 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 separate tables referred to as the delta tables.
Users can edit all the versions simultaneously. Multiple users can also edit the same version at the same time.
As more versions are created, a tree-like architecture begins to develop, similar to a family tree. This is called a version tree. For the sake of simplicity and geodatabase management considerations, a recommended best practice is to maintain a flat version tree or have multiple editors concurrently editing the Default version.
Connect to a specific geodatabase version
By default, the Database Connection dialog box connects to the Default version when connecting to a geodatabase. You might need to connect to a different version, though. Reasons for this include the following:
- You frequently edit a geodatabase version other than Default.
- You want to connect to a user-schema geodatabase in Oracle.
Follow these steps to connect to a transactional version other than Default:
- Connect to your geodatabase in the Databases folder in the Catalog pane.
- Right-click your database connection and click Geodatabase Connection Properties.
- Choose a version.
- Choose from the Transactional version list to connect to a transactional version.
- Choose from the Schema list to connect to a user-schema geodatabase in Oracle.
- Click OK.
Each time you use this connection, you will connect to the version you specified. To change to a different version, repeat these steps.
As mentioned previously, when you initially add data from an enterprise geodatabase connection to the map, the data comes from the Default version unless you change the database connection in your project to use a different transactional version.
Once you've added data to the map, you can display any transactional version and change from one version to another using the Change Version dialog box.
Follow these steps to change the version displayed for all layers in the map that share the same enterprise geodatabase data source:
- Click the List By Data Source button on the Contents pane.
- Right-click the data source version in the Contents pane and click Change Version.
- Choose a version from the list and click OK.
When you change from one version to another, all feature classes from that geodatabase present in the map change to the version to which you have switched.
Switching between versions in the map allows you to see the changes made to the feature classes. This is useful when you are reviewing edits prior to merging changes with those in an ancestor version through a process called reconcile and post.
Reconcile and post changes
Reconciling and posting integrates 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 ancestor 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. For more details on this process in ArcGIS Pro, see Reconcile and post edits to a version.