Register a dataset as branch versioned

Available with Standard or Advanced license.

When you initially add or create a dataset in an enterprise geodatabase, the dataset is not registered as versioned, and it is considered nonversioned data. Before you can edit a dataset in a version, you must register the dataset as versioned. To learn more about why you would want to edit a dataset in a version, see Overview of versioning.

There are two versioning types you can use when registering datasets as versioned:

• Branch versioning—Facilitates the Web GIS model by allowing multiuser editing scenarios and long transactions via feature services. For more information, see branch version scenarios.
• 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. For more information, see traditional version scenarios.
  • 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

Learn more about versioning types

Note:

Regardless of the type of versioning used, it is recommended that you complete any data loading before registration. All versioning types add a number of system-maintained tables, indexes, and attributes that can add to the processing time of data loading operations.

Register a dataset as branch versioned

Prerequisite:

Before you can register a dataset as branch versioned, there are a number of requirements that must 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 dataset properly to accommodate a variety of workflows.

To register a dataset as branch versioned, the following requirements must be met:

• The enterprise geodatabase must be 10.6 or later. The following database platforms are supported:
  • IBM Db2
  • Microsoft SQL Server
  • Oracle
  • PostgreSQL
  • SAP HANA

  Note:

  Refer to the requirements and limitations section for the specific database requirements topic. Use the links in Supported databases to access the system requirements for the database you want to use.
• The dataset must have global IDs and editor tracking enabled using UTC time standard.
• Datasets cannot be versioned using traditional versioning or have archiving enabled.
• For datasets participating in relationship classes, the primary key of the relationship must not use the Object ID field. For more information, see Relationship class properties.
• Any unique indexes on the dataset's underlying database table must be removed.

The following data types are not supported:

• Raster
• Oracle compressed tables

Caution:

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.

To register a dataset as branch versioned, complete the following steps:

1. Connect to your enterprise geodatabase as the dataset owner in the Databases folder in the Catalog pane.
2. Ensure the database connection has the Versioning Type set to Branch. Use the Geodatabase Connection Properties dialog box for the database connection to update the Versioning Type setting to Branch.

   You can also use the Update Geodatabase Connection Properties To Branch tool to update the Versioning Type setting for the database connection.

3. Ensure the dataset has global IDs. To add global IDs to a dataset, right-click the dataset, click Manage, and click Add Global IDs.

   You can also use the Add Global IDs tool.

4. Ensure the dataset has editor tracking enabled using the UTC time standard. To enable editor tracking, right-click the dataset, click Manage, and click Enable Editor Tracking.

   You can also use the Enable Editor Tracking tool.

5. Right-click the dataset, click Manage, and click Register as Versioned.

   You can also use the Register As Versioned tool.

The dataset is now registered as branch versioned.

At the time of registration, a number of modification operations occur on the dataset. Four 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

The two additional attributes below are added to the feature class or table and allow tracking of deletions; these work in conjunction with the standard editor tracking fields.

• GDB_DELETED_AT
• GDB_DELETED_BY

After registering as branch versioned, the next step is to publish the datasets to your organization's portal. This will make the data accessible for editing as a web feature layer.

To learn more, see Share branch versioned data.

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 if you need to perform data loading and don't want the overhead from the extra version tables and indexes. To unregister as versioned, an exclusive lock is required on the dataset.

Caution:

When you unregister a dataset as versioned, all versioned edits made in named versions that are not posted to default will be deleted. To prevent these edits from being lost, ensure that all named versions are reconciled and posted to default before unregistering the dataset as versioned.

To unregister a feature dataset, stand-alone feature class, or table as versioned, right-click the dataset in the Catalog pane, click Manage, and click Unregister As Versioned. You can also use the Unregister As Versioned tool.