Available with Standard or Advanced license.
Versioning can be applied in various scenarios and can vary depending on the business requirements of each organization. General considerations for editing workflows and recommended versioning configurations are described with illustrations below.
Workflows vary 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 single unit of work, such as a work order. To manage each work order, you can create a separate, isolated version and modify it. Once this work is complete, you can integrate the changes into the published version of the database. Working with versions in this way allows you to accommodate the most basic of workflow processes as well as the most complex.
The concept of versioning is the same whether you are using branch versioning or traditional versioning. Versioning provides multiple representations of the data without copying data, allows concurrent editing, and allows users to have versions for extended periods of time. See an overview of versioning for more details.
Traditional versioning provides the flexibility to work in versions for long transactions when accessed directly from the enterprise geodatabase as well as a simplified editing experience when using feature services to accommodate shorter transactions.
You will most likely use either the concurrent editing of the published database configuration, with multiple editors modifying the default version, or a combination of the other configurations. An understanding of the organizational and business requirements and an appreciation of the benefits and limitations of each traditional version scenario will help you choose what's best for your organization.
For simplicity and geodatabase management considerations, a recommended best practice is to maintain a flat version tree.
Edit the default version
The default version is the initial version created when data is registered as traditional versioned. When you use traditional versioning and the version access is set to public, multiple editors can concurrently edit and view data using the default version. The simplest way to support multiuser editing is to allow multiple editors to edit the default version directly.
As each editor starts editing the default version, an unnamed, temporary version is automatically created in the edit session. This temporary version is accessible only to the current editor. When the editor saves his or her work or ends the edit session, the changes recorded in the temporary version are posted to the default version.
If another editor has edited the default version since you started editing, when you save your work, ArcGIS automatically reconciles and posts your changes. You are notified that the version has been changed and must save again to accept the changes made by other editors. If there are conflicts, you must resolve them using the conflict resolution dialog box before you can successfully save your edits.
Considerations
Consider the following benefits and limitations when working with or editing the default version:
- Benefits
- This strategy supports simple database modifications well because users do not have to create new versions to edit data. This is appropriate when the units of work are fairly small or when persistent design alternatives are not required.
- If there are no conflicts, saved edits are posted directly to the default version.
- Limitations
- The default version is constantly changing and is vulnerable to accidental or unauthorized modification; therefore, the database administrator may need to back up the database more frequently.
- Long-duration transactions or the creation of alternative design versions that span many edit sessions are not supported.
- Only one reconcile operation per geodatabase can be active at any given time. If there are frequent reconcile and post operations from various edit sessions, editors saving their changes may need to wait for active reconcile and post processes to complete. In a large, multiuser geodatabase, it is better to avoid situations where many users reconcile and post to a common version. Reconciling and posting exclusively locks the version. While this lock is in place, other users are prevented from completing their tasks.
Edit a child version
If you're managing multiple projects, work orders, or jobs, you'll require a structured approach to workflow management. Discrete work units involving many edit sessions and spanning numerous days, weeks, or months can be maintained without affecting the default version. Examples of these discrete work units are a highway improvement scheme, the installation of a new phone service, or an ongoing maintenance project for a gas pipeline.
If you're using traditional versioning, when a work order or project is initiated, a version is created as a child of the default version.
One or more editors can work on this version until the work order or project is complete. When all the modifications to a child version have been completed, an editor or administrator reconciles with the default version, resolving any conflicts. The modifications to the default version are then posted, integrating the modifications into the published database. At this point, the child version can be removed.
User access permissions to the default version can be restricted to enforce this workflow and ensure that the default version is not modified. The administrator can set the permission of the default version to protected, allowing users to continue to view the default version but restricting their access level to read-only. Any editor wanting to modify the data must create a new child version.
When you use traditional versioning, version access is determined by a combination of the database user's privileges and the access permission level (public, protected, or private) set for the version.
Considerations
Consider the following benefits and limitations when working with or editing a child version:
- Benefits
- Simplicity—Each work unit is logically segregated by version.
- Long-duration transactions spanning many edit sessions are supported, as well as the creation of alternative designs, allowing editors to develop proposals without affecting the production database.
- Creating a new version from the default version protects the production view of the database from unintentional modification. Individual work projects are integrated with the production database when completed.
- Batch reconcile and post processes are supported.
- Limitations
- As with any multitier version configuration, the more rows that are maintained in the version delta tables, the greater the potential impact on version query performance. This overhead can be minimized by compressing the database regularly and updating the DBMS statistics.
Support editors and viewers
If your organization needs to support a group of editors as well as users accessing the system with read-only access, the editors use the traditional versioning workflow outlined in the Edit a child version scenario. If your read-only users do not require the ability to see changes as soon as they are posted to the default version, you can create a protected, static version from the default version for them to use. This version should be created after the database has been compressed and the indexes and statistics rebuilt. Doing so ensures that all the rows required to represent the read-only version are stored in the base table and that the database is performing optimally. In this scenario, no changes are made to the read-only users' version of the database, so version difference queries don't need to be performed and the database statistics and indexes do not become out of date or fragmented. After each scheduled database compression, this version is re-created, allowing the read-only users access to changes made since the last database compression.
Distributed data management
There are multiple ways to distribute versioned data among your organization to facilitate different workflows.
Geodatabase Replication
Geodatabase replication works directly with geodatabases or geodata services and supports workflows for keeping them in sync. Tools are provided in ArcGIS AllSource for performing geodatabase replication as were provided in ArcGIS Desktop. Most of these workflows require traditional versioned data.
For example, some projects require two or more distant offices to work on the same data. Each office requires local access to the database, so each creates a copy of the database. When a change is made to the data in one office location, the change must also be applied to the data in the other office location. To keep the copies of the databases synchronized, the offices can transfer changes between each other on a scheduled basis. This capability is referred to as geodatabase replication.
Replication is also helpful to an editor who may otherwise have to edit data over a slow network. In this case, replication allows a subset of the data to be extracted to a local machine so that the editor can work on it without using the network. Once the edits are complete, they can be transferred over the network, merging them back into the production database. For more information, see Distributed data scenarios.
Feature Services
Traditional versioned data can also be published as sync enabled feature services. These support workflows with mobile data collection apps or ArcGIS AllSource where editors can download a copy of the data, make local edits and then call sync on the feature service. When working with traditional versioned data and mobile editors, learn how to use and work with traditional versioned data in feature services that you take offline.
Feature services can also participates in distributed collaboration workflows. For example, distributed collaboration (or simply collaboration) supports feature services that include feature layers running on traditional versioned data. It allows sync-enabled feature services to be shared as a copy when the feature services shared across the collaboration are running separate copies of the data. To learn more about the collaboration process and collaboration concepts, see How collaboration works.