Workflows using geographic data can vary widely in duration and complexity. Enterprise geodatabases support two data management strategies that balance the workflow needs of users and applications to perform short and long transactions on data: data management with versions and without versions. The nonversioned approach manages short transaction editing, and versioning accommodates long transactions.
Each strategy, whether with or without versions, can be applied on a feature-class-by-feature-class or table-by-table basis, so it's possible to make use of both in the same enterprise geodatabase. Versioned data management is further expanded into three options: branch versioning, traditional versioning, and versioning with the option to move edits to base. The strategy you choose will be determined by the capabilities that you want in your GIS, as there are some differences in which data you can edit and the types of workflows you can perform.
Refer to the following table for a summary of the editing workflow options supported in an enterprise geodatabase:
| Data types | Branch versioning | Traditional versioning | Traditional versioning (move edits to base) | Nonversioned editing |
|---|---|---|---|---|
Feature class |  | | | |
Table | | | | |
Annotation | | | | |
Dimension | | | | |
Relationship class | | | | |
Trace network ** | ** | |||
Utility network | | |||
Parcel fabric | | |||
Topology | | | ||
Network dataset | | |||
Terrain dataset | |
**Supported only in a file geodatabase
Data management without versioning
This strategy does not involve working with multiple versions of your data; it makes use of the underlying DBMS transaction model. Nonversioned edits are equivalent to standard database short transactions.
To edit data, click the Edit tab on the ribbon and perform the required operations, such as adding, deleting, or moving features and updating attributes. Your first edit in the edit session begins the transaction, and the individual edit operations you perform are each committed to the database as a single transaction. When editing nonversioned data in ArcGIS Pro, each transaction is automatically committed to the database without needing to save the edits. The changes you make are available to all other users and applications accessing the data when your transaction is complete.
As you edit, any unique indexes, constraints, and triggers defined on the data with the DBMS apply. All the same locking behavior applies as if you were performing transactions on the data with the DBMS directly. Therefore, there is the potential for users or applications that access or modify the same data to block one another.
Note:
When using nonversioned editing in a multiuser editing environment, you should understand how isolation levels and locking work in your DBMS and, if necessary, set the correct isolation level in the DBMS before you start working with ArcGIS.
This strategy is appropriate for simple features for which you don't need to work with multiple representations of the data within versions. Since this strategy doesn't use versions, it's also useful if you require both GIS and non-GIS applications to share access to a common database.
Benefits
Benefits of nonversioned data management include the following:
- Integrate geographic data into existing applications by allowing third-party applications (those not created with Esrisoftware) to read and modify the same data that is accessed by ArcGIS applications. For example, business partners of Esri frequently build add-ons and extension applications that require open access to update the data stored in the underlying DBMS.
- Manage projects with simple workflows and edits. If transactions are always simple and of short duration, you can modify the data directly without the need to merge changes and periodically manage additional tables that are required for versions.
Limitations
Limitations of nonversioned data management include the following:
- You can only edit simple features: points, lines, polygons, annotation, and relationships. You can't edit feature classes that participate in a topology, utility network, parcel fabric, or other datasets with advanced functionality.
- Since you edit the data source directly, you cannot undo or redo an individual edit if you make a mistake.
- There is no conflict detection with nonversioned editing. If one user updates a feature and saves, and another user updates the same feature and saves, the last update made overwrites the first.
- In multiuser editing scenarios, as one user edits a feature, locks are applied by the DBMS, preventing other editors from making simultaneous edits to that same feature.
Data management with versioning
The enterprise geodatabase uses versioning to accommodate the needs of multiuser editing scenarios and long transactions. The geodatabase extends the standard DBMS transaction model by allowing multiple concurrent states of the databases, known as versions, to exist at the same time. This allows multiple users to edit the same data in the geodatabase at the same time, without applying locks or duplicating data.
Editors can work within their own personal version of the geodatabase so that other users don't see incomplete work and editors don't block one another from accessing the data.
Each version can represent ongoing work, such as a design or a group of work orders, work that can span multiple connections to the database and extend over a period of weeks or months if necessary. Once an editor has completed their work, they can integrate their changes back into the parent version.
Here are some example workflows using versions:
- Projects requiring a what-if analysis—Create a design in a separate version. If the design is approved, you can merge it with the rest of the database. If it is not approved, you can discard it.
- Projects with specific quality assurance requirements—Collect changes to data, such as bulk imports, in a version isolated from other database users. Test and approve the changes before merging them with the published version of the database.
- Projects that divide work into functional or geographic units—For example, a project to design and construct a new shopping mall may have distinct construction phases subdivided into east and west sections or by construction activities, such as building, utility installations, or landscaping. Each unit of work is undertaken in a separate version; as each version is completed, it is posted to the published version of the database.
- Projects that evolve through a prescribed or regulated group of stages, whereby each stage requires engineering, administrative, or legal approval before it can be considered complete—Workflows for these projects can manage each stage as a separate version, such as an initial design or proposed version, an approved version, and a version for the construction phase. As a project advances through the various milestones, each stage is reviewed and approved, and then superseded by the next version until the last stage is reached and completed.
- Projects that require maintenance crews in the field to update data with mobile devices—Editors in the field can work within their own versions and merge changes with the updates made by editors back in the office.
Every enterprise geodatabase has a version named Default. 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, as with any other version. The Default version is the root version and, therefore, the ancestor of all other versions.
Versioning allows flexibility and scalability in your data management strategies. There are two types of versioning available, each catering to particular workflows and deployment options:
See branch version scenarios and traditional version scenarios for configurations that illustrate how the versioning technology can be applied within an organization.