Available with Standard or Advanced license.
When you initially add or create a dataset in an enterprise geodatabase, the data is not registered as versioned, and it is considered non-versioned data. Before you can edit a dataset within a version, it must first be registered as versioned. There are two versioning types that can be used when registering datasets as versioned:
- Branch versioning—Facilitates the WebGIS model by allowing multiuser editing scenarios and long transactions via feature services
- Traditional versioning—Provides the flexibility to work within versions for long transactions when accessed directly from the enterprise geodatabase, and a simplified editing experience when using feature services to accommodate shorter transactions
- Traditional versioning with the option to move edits to base—An optional form of traditional versioning that allows editors and applications to have direct access to the base data while also allowing other editors to work in their own isolated versions
For more information on versioning types and why you would use each one, see Enterprise data management strategies.
Regardless of the type of versioning you'll be using, it is recommended to do any data loading prior to registration. All types of versioning add a number of system maintained tables, indexes and attributes which can add to the processing time on any data loading operations.
Register a dataset as branch versioned
Before you can register data as branch versioned there are a number of requirements that need to be met. Since branch versioned feature services are designed for Web GIS and used throughout the platform, offline, and across portals, it is important to prepare the data properly to accommodate a variety of workflows.
In order to register a dataset as branch versioned the following requirements must be met:
- The enterprise geodatabase must be 10.6 or newer
- Minimum database requirements—Refer to the requirements and limitations section for the specific database requirements topic; see Supported database management systems.
- The database connection must be explicitly set to Branch for the Versioning Type. Set the geodatabase connection properties for the database connection to Branch for the Versioning Type. The Update Geodatabase Connection Properties To Branch tool can also be used to update the Versioning Type for the database connection.
- The dataset must have global IDs—To add global IDs to a dataset, use the Add Global IDs geoprocessing tool.
- The dataset must have editor tracking enabled using the UTC time zone.
- Datasets cannot be versioned (traditional versioning) or have archiving enabled.
- For datasets participating in relationship classes, the primary key of the relationship must not use the ObjectID field. For more information, see Relationship class properties.
- Any unique indexes on the dataset's underlying database table must be removed.
- You must be connected to the master SDE user schema for an Oracle geodatabase. User schema geodatabases are not supported.
The following data types are not supported:
- Oracle compressed tables
When all of the above conditions are met, you can register a stand-alone feature class or table as branch versioned by right-clicking it in the Catalog pane and selecting Manage and then Register as Versioned. The Register As Versioned tool can also be used.
Once you have registered a dataset as branch versioned, the minimum client version to access the dataset is ArcGIS Pro 2.1. This also means that the dataset will no longer be available for use in ArcMap.
At the time of registration a number of modification operations occur on the dataset. Four new system attributes are added to the feature class or table. These attributes are used in managing versioned representations of the features and objects:
- GDB_FROM_DATE—The moment in time of an edit
- GDB_IS_DELETE—Marks the feature as active or retired
- GDB_BRANCH_ID—A branch identifier to isolate edits
- GDB_ARCHIVE_OID—The unique row identifier
Two additional attributes are added to the feature class or table that allow for the tracking of deletions; these work in conjunction with the standard editor tracking fields.
After registering your data as branch versioned, the next step towards editing and using the data in branch versioning workflows is to publish the data to your organization's portal. Once registered as branch versioned, the data can no longer be edited when accessed directly from the database connection. You'll still be able to view the data when connected to the default version, and make schema changes directly from the database connection.
To learn more, see Share branch versioned data.
Register a dataset as traditional versioned
Before registering your data as versioned using traditional versioning, first check that your geodatabase connection is set for traditional versioning. Right-click the geodatabase in the Catalog pane and click Geodatabase Connection Properties. In the Geodatabase Connection Properties dialog box, choose Traditional under Versioning Type.
To register a feature dataset, stand-alone feature class, or table as traditional versioned, right-click it in the Catalog pane, point to Manage, and click Register As Versioned. This opens the Register As Versioned dialog box. Leave the Move Edits to Base option unchecked and click OK.
When you register your data as traditional 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.
Registering a dataset creates the supporting delta tables: the adds (A) and deletes (D) tables, as well as attribute indexes. The A and D tables and their attribute indexes have the potential to be among the most active in your geodatabase. In this case, these tables are read during all queries against the feature class or table. Also, anytime a user makes an edit, a row is added to one or both of these tables, so these tables will grow quickly in an actively edited geodatabase. For this reason, data administrators will need to plan for their storage and periodic compression operations to maintain optimum performance. For more information on version administration tasks, see Recommended version administration workflow
Register as versioned with the option to move edits to base
Registering data as versioned with the option to move edits to base is designed to support non-versioned edits by third-party applications while still offering the traditional versioning benefits of long transactions and isolated editing. This option is available for simple features only—those that do not participate in a topology, network dataset, or a utility network.
To register a feature dataset, stand-alone feature class, or table as versioned with the option to move edits to base, right-click it in the Catalog pane and selecting Manage and then Register As Versioned. This opens the Register As Versioned dialog box. Check Register the selected objects with the option to move edits to base. Checking this option causes edits that have been saved to the DEFAULT version, whether edited directly or merged from other versions, to be saved in the base (business) tables. Edits to other versions remain in the delta tables when you save.
Unregister a dataset as versioned
You may want to unregister a dataset as versioned if it is no longer needed in the versioning environment or perhaps you need to perform some data loading and don't want the overhead from the extra version tables and indexes.
To unregister a feature dataset, stand-alone feature class, or table as versioned, right-click the dataset in the Catalog pane, point to Manage, and click Unregister As Versioned.
When you unregister a feature class from traditional versioning, the delta tables are dropped from the database. That means all versioned edits that were made but not posted will be lost. The software prompts you to compress the edits to the base table when you attempt to unregister a feature class from traditional versioning. To prevent these edits from being lost, either compress all the edits to the base table before unregistering the data or compress them to the Default version from the Unregister As Versioned dialog box.