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, 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 WebGIS and used throughout the platform, offline, and across portals, it is important to get the data prepared properly to accommodate such a variety of workflows.
In order to register a dataset as branch versioned the following requirements must be met:
- Minimum geodatabase requirements—Branch versioning is only available for 10.6 enterprise geodatabases
- Minimum database requirements—Branch versioning is available for multiple databases platforms, each has a minimum release that can support it:
- PostgreSQL 9.5.3
- SQL Server 2012 sp3
- SAP HANA 2 SPS02
- DB2 10.5 FP5
- Oracle 188.8.131.52, also keep the following things in mind when using Oracle:
- User schema geodatabases do not support branch versioning
- You must be using the ST_GEOMETRY spatial data type
- Branch versioning geodatabase connection—Your geodatabase connection must be explicitly set to the branch versioning type of connection.
- To change your geodatabase connection type to branch versioning, right-click the geodatabase in the Catalog pane and choose Geodatabase Connection Properties. In the Geodatabase Connection Properties dialog box, choose Branch under Versioning Type.
- You can also change your geodatabase connection type to branch versioning using the Update Geodatabase Connection Properties to branch geoprocessing tool.
- The dataset must have global ids enabled—The global id column is used to uniquely identify a feature or table row within geodatabases and across geodatabases.
- To add global ids to a dataset you can use the Add Global IDs geoprocessing tool.
- The dataset must have full editor tracking enabled and be set up to track time in UTC. It doesn't matter if you use the defaults or user-defined fields, as long as all 4 editor tracking fields are present. For more details on editor tracking, see About tracking an editor's changes to data.
- To enable editor tracking, right-click the dataset in the Catalog pane and selecting Manage and then Enable Editor Tracking.
- You can also enable editor tracking by using the Enable Editor Tracking geoprocessing tool.
- Datasets can't already be registered with another type of versioning. You will have to unregister the dataset as versioned before proceeding.
- Datasets can't have archiving enabled on them. You will have to disable archiving on the dataset before proceeding.
- For datasets participating in relationship classes, the primary key of the relationship must not be the ObjectID field.
- Any unique indexes on the dataset's underlying database table need to be removed.
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. This can also be done on a feature dataset to register all feature classes within it as branch versioned, as long as all of them meet the above requirements.
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
As mentioned above, editor tracking must first be enabled before registering a dataset as branch versioned. Once the dataset is registered two other attributes are added to the feature class or table that also allow for the tracking of deletions within the class:
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.
Learn more about how to Share branch versioned data
Registering 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 choose Geodatabase Connection Properties. In the Geodatabase Connection Properties dialog box, choose Traditional under Version Type.
To register a feature dataset, stand-alone feature class, or table as traditional versioned, right-click it in the Catalog pane and selecting Manage and then 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
Registering 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 it in the Catalog tree, point to Manage and select 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.