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 data management without versions. The nonversioned approach manages short transaction editing, and the versioned approach 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 use 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 is determined by the capabilities that you want in your GIS, as there are differences in the data that you can edit and the types of workflows you can perform.
The following table provides a summary of the editing workflow options supported with these dataset types 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 | | | | |
3D Object feature class | | |||
Trace network | | |||
Utility network | | |||
Parcel fabric | | |||
Topology | | | ||
Network dataset | | |||
Terrain dataset | |
Note:
In addition to the dataset types listed in the table above, there are other geodatabase capabilities, such as replication, archiving, attribute rules, and so on, that only work with certain geodatabase registration data types. Consult these individual capability topics for details.
Data management without versioning
This strategy does not involve working with multiple versions of your data; it uses 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 so you do not need 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, unique indexes, constraints, and triggers that are defined on the data with the DBMS apply. The same locking behaviors apply as if you were performing transactions on the data with the DBMS directly. There is the possibility that users or applications that access or modify the same data may 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 (those that don't include 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 Esri software) 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 merging 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 .
- There is no conflict detection with nonversioned editing. If one user updates a feature and saves their change, and another user updates the same feature and saves their change, 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 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 in 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, 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.
The following are 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 in their own versions and merge changes with the updates made by editors 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 the ancestor of all other versions.
Versioning allows flexibility and scalability in data management strategies. There are two types of versioning available, each applicable 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 in an organization.