Last modified April 2, 2009
Print all topics in : "Working with versioned data"
Workflows vary greatly from organization to organization. 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.
This topic presents the application of versioning—how this technology may be applied within an organization—and illustrates the version configurations that are available.
You will most likely adopt either the concurrent editing of the published database, with many editors modifying the DEFAULT version, or some combination of the other configurations. An understanding of the organizational and business requirements and an appreciation of the pros and cons of each configuration will help you choose what's best for your organization.
Many users can edit the same version simultaneously, so the simplest way to support multiuser editing is for many editors to directly edit the DEFAULT version.
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 work or ends the edit session, the changes recorded in the temporary version are posted to the DEFAULT version.
If another user has edited the DEFAULT version since you've started editing, when you save your work, ArcGIS automatically reconciles and posts the changes. You are notified that the version has been changed and must save again to accept the changes made by other editors. You can bypass this warning message by enabling autoreconciliation in the ArcMap Options dialog box. Regardless of whether you bypass this message, if there are conflicts, you must resolve them with the conflict resolution dialog box before you can successfully save your edits.
Learn more about settings for saving data.
Learn how to resolve data conflicts.
If you're managing multiple projects or work orders, you'll require a more structured approach to workflow management. Discrete work units involving many edit sessions and spanning a number of days, weeks, or months can be maintained without affecting the DEFAULT version. Examples of these discrete work units could be a highway improvement scheme, the installation of a new phone service, or an ongoing maintenance project for a gas pipeline.
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 version have been completed, the editor or the ArcSDE administrator reconciles with the DEFAULT version, resolving any conflicts that arise. He or she then posts the modifications to the DEFAULT version, integrating the modifications into the published database. At this point, the version can be removed.
User access permissions to the DEFAULT version may be restricted to enforce this workflow and ensure that the DEFAULT version is not modified. The ArcSDE administrator may set the permission of the DEFAULT version to protected; this allows users to continue to view the DEFAULT version but restricts their access level to read-only. Any editor wishing to modify the data must create a new version.
If your read-only users do not require the ability to see changes as soon as they are posted back to the DEFAULT version, you could 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 will ensure all the rows required to represent the version are stored in the base table and that the database is performing optimally. In this scenario, no changes are being made to the read-only users' version of the database (FastTrak in the illustration below), so version difference queries don't have to be performed and the database statistics and indexes will not become out-of-date or fragmented. After each scheduled database compress, this version would be re-created, allowing the read-only users access to changes made since the last database compress.
Complex projects will require a more elaborate workflow structure than that provided by either the concurrent editing or the multiple project approach. These projects may further divide into multiple functional or geographic units from which a more complex versioning hierarchy will develop. For example, a project to design and construct a new shopping mall might have distinct construction phases subdivided into east and west sections or by construction activities such as building, utility installations, or landscaping.
For large projects involving different teams and numerous discrete units of work, a multiple-tier version tree is an effective way to organize the workflow. The teams working on different aspects of the same project create their own version to maintain a private view of their updates. Once the project has been completed, the versions can be reconciled and posted back to the DEFAULT version and become an integral part of the published database.
Many projects evolve through a prescribed or regulated group of stages that require engineering, administrative, or legal approval before proceeding to the next stage. For example, within the utility domain, common project stages include working, proposed, accepted, construction, and as built. This particular process is essentially cyclical: a work order is initially assigned to an engineer and modified over time as the project evolves through the various stages before full integration with the production database.
In this approach, a version is created to represent each stage of this process: initial design or proposed version, an approved version, and a version for the construction phase. As the project advances through the various project milestones, each stage is reviewed and approved, then superseded by the next version until the last stage is reached and completed. The older versions may be maintained for historical reference or deleted as required.
Once the project is complete, the constructed version can be reconciled with and posted directly to the DEFAULT version without having to reconcile and post with the previous versions in the lineage.
A key requirement for many projects is the preservation of various states of the database as it changes over time. Some of the typical queries a geodatabase may have to support include
Some projects require two or more distant offices to work on the same data. The offices each require local access to the database, and so create a copy of the database. When a change is made to the data in one location, the change must also be applied to the data in the other location. To keep the copies of the databases synchronized, the sites can transfer changes between each other on a scheduled basis. This capability is referred to as geodatabase replication.
Replication also allows you to take subsets of the geodatabase on the road and edit offline, a common requirement for field maintenance crews. Once you return to the office, you can reconnect to the network and merge the changes back into the production database.
Replication is also helpful to anyone who would otherwise have to edit data over a slow network. In this case, replication allows you to extract a subset of the data to your local machine so that you can work on it without having to communicate over the network. Once you're finished editing, you can transfer the changes over the network, merging them back into the production database. For more information, see Scenarios using distributed data.