Available with Standard or Advanced license.
The datasets in your enterprise geodatabase can be registered as versioned without the option to move edits to base, registered as versioned with the option to move edits to base, or not registered as versioned. By default, when you add or create a dataset in an enterprise geodatabase, the data is not registered as versioned. For an introduction to these options and why you would use them, see Data maintenance strategies.
Data owners can register their data as versioned from ArcGIS Desktop by right-clicking the dataset, pointing to Manage, and clicking Register As Versioned. They must decide whether to use the move edits to base option based on the type of data they have and how they want to edit it. Later, if the data owner needs to unregister the data as versioned, he can right-click the dataset, point to Manage, and click Unregister As Versioned. Doing so drops the delta tables and any data left in them. Therefore, outstanding edits should be compressed to the base table or the DEFAULT version before unregistering the data as versioned.
Registering as versioned without the option to move edits to base
Registering your data as versioned without the option to move edits to base allows you to take advantage of all versioned editing functionality. This includes the following:
- Undo and redo edits.
- Perform long transaction edits.
- Use named versions for designs and projects.
- Use geodatabase archiving.
- Use replication.
- Place a unique constraint on the base table of a feature class.
However, before you register data, consider that there are certain ArcGIS operations you can't perform on data that is registered as versioned. These operations are as follows:
- Create a topology.
- Create a geometric network.
- Add or remove a feature class from a geometric network.
- Create a network dataset.
- Add or remove a feature class from a network dataset or make other schema changes.
Additionally, when importing a large amount of data, performance is better if you import to a feature class or table that hasn't been registered as versioned.
If you decide to register a feature dataset, stand-alone feature class, or table as versioned, right-click it in the Catalog tree, point to Manage, then 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 leave this option unchecked, edits to all versions, including the DEFAULT, are preserved in the delta tables.
Note to the database administrator
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, you need to plan for their storage and periodic compression to maintain optimum performance.
Registering as versioned with the option to move edits to base
Registering data as versioned with the option to move edits to base allows you to perform versioned edits on the data. Although registering data this way is designed to support nonversioned edits by third-party applications, you can't perform nonversioned edits through ArcGIS.
Keep in mind that, in addition to the ArcGIS operations you can't perform when the data is registered as versioned (as described above), if you register data as versioned and specify the option to move edits to base, you cannot do the following:
- Edit feature classes that participate in a topology, network dataset, or geometric network.
- Archive data with the archiving functionality built into the geodatabase.
- Make use of geodatabase replication.
If you decide 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 tree, point to Manage, then click Register As Versioned to open 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.
This option is available for simple features only—those that do not participate in a topology, network dataset, or geometric network. Therefore, if you open the Register As Versioned dialog box and find the move edits to base tables check box is unavailable, it means your dataset contains a topology, network dataset, or geometric network.
Not registered as versioned or unregistering data as versioned
As mentioned above, your data is initially not registered as versioned. If it remains in this state, you can perform nonversioned edits, and you can create a topology, network dataset, or geometric network.
If you've already registered a feature class as versioned and need to perform one of the above operations, you must unregister the feature class as versioned. When you unregister a feature class, the delta tables are dropped from the database—that means all versioned edits that were made but not posted will be lost. 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. The software prompts you to compress the edits to the base table when you attempt to unregister a feature class as versioned.
You can access the Unregister As Versioned command from the dataset context menu.
To avoid the need to unregister feature classes, try to apply all topology, network dataset, and geometric network behavior to your geodatabase before you register data. Test the topology, network dataset, and geometric network in a file geodatabase or on a development server to ensure that you are not missing any rules. This can save you from having to unregister feature classes later in production.