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
Regardless of the type of versioning used, it is recommended that you complete any data loading prior to 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
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
- Minimum database requirements—Refer to the requirements and limitations section for the specific database requirements topic. Use the links in Supported database management systems to access the system requirements for the database you want to use.
You must connect to the master SDE geodatabase in Oracle. User schema geodatabases do not support branch versioning.
- 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.
Note:Branch versioning is now supported for datasets that use SDO_Geometry spatial data storage in enterprise geodatabases in Oracle.
The following data types are not supported:
- Oracle compressed tables
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:
- Connect to your enterprise geodatabase as the dataset owner in the Databases folder in the Catalog pane.
- 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 to Branch.
You can also use the Update Geodatabase Connection Properties To Branch tool to update the Versioning Type for the database connection.
- 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.
- Ensure the dataset has editor tracking enabled using the UTC time zone. To enable editor tracking, right-click the dataset, click Manage, and click Enable Editor Tracking.
You can also use the Enable Editor Tracking tool.
- Right-click the dataset and click Manage, and click Register as Versioned.
You can also use the Register As Versioned tool.
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.
After registering your dataset as branch versioned, the next step toward editing and using the dataset 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 can still 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.
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. The Unregister As Versioned tool can also be used.