You have the option to enable archiving on traditional versioned or nonversioned data to track historical data.
For branch versioning, the ability to track historical edits using archiving is enabled automatically during the register data as branch versioned process. Learn more about the requirements and process to register a dataset as branch versioned.
To enable archiving on traditional versioned or nonversioned data, complete the following steps:
- Connect to your enterprise geodatabase as the dataset owner in the Databases folder of the Catalog pane .
- Right-click the dataset and click Manage.
The properties dialog box appears with the Manage tab active.
- Check Archiving.
- Click OK to apply the changes.
To enable archiving on multiple datasets at once, you can use the Enable archiving geoprocessing tool.
The geodatabase manages archiving on your dataset differently, depending on whether or not the dataset is versioned.
Enable archiving on versioned data
Enabling archiving on versioned data is similar to registering a dataset as versioned. For each dataset for which archiving is enabled, a new archive class is created. When enabling archiving, all attributes and all rows in the default version of the dataset or object class are copied to the archive class. The time it takes to complete the creation of the archive class depends on the size of the dataset being enabled. The archive class has the same schema as the original dataset, with additional date attributes gdb_from_date and gdb_to_date to record the timestamp for the effective life-span of the archived row and a gdb_archive_oid attribute to uniquely identify each row.
Representing the archive class as an independent feature class, as opposed to managing the historical rows in the delta table for the versioned table, means that the existence and size of the archive does not impact the efficiency of the database. Datasets can be unregistered as versioned without affecting or deleting the archive class. If a dataset is unregistered as versioned, the archive class becomes an object or feature class.
Once the dataset has had archiving enabled, all changes saved or posted to the default version are additionally preserved in the archive class. You do not have the ability to append historical data to the archive class. Manually changing the archive class can lead to corruption of your geodatabase archiving process.
Enable archiving on nonversioned data
When you enable archiving on nonversioned data, the geodatabase creates additional date attributes in the base table for that dataset. These date attributes are columns in the base table, named gdb_from_date and gdb_to_date, and are used to record the time stamp for the effective life-span of the archived row. As edits are made to the dataset, these attributes are updated to maintain an historical record over time.
Nonversioned archiving is supported on tables and SQL spatial types such as SQL Server Geometry, ST_GEOMETRY, and SDO_geometry but not on older geometry types such as SDEBINARY and SDELOB.
Keep the following in mind when enabling archiving:
- If a versioned dataset is registered with moving edits to base, archiving cannot be enabled. It must be unregistered and registered as versioned without the option to move edits to base.
- You cannot enable versioning on a dataset that already has archiving enabled on it. You must disable archiving, register the dataset as versioned, and reenable archiving.
- Branch versioned datasets have archiving enabled during the register as versioned process. There is no separate process required to enable archiving to track historical edits for branch versioned datasets.
- You can only enable archiving on datasets or classes you own.
- Enabling archiving traverses relationship classes.
- Indexes on the origin class will also be created on the archive class during the enable archive phase.
- You can view the time and date when archiving was enabled by opening the properties dialog box of a feature class or table. Right-click the object and choose Properties. On the Source tab, under Data Source, there is an Archiving property that has a description of when the object was enabled for archiving.
- The default naming convention for the archive class is the name of the object class followed by an underscore and an H. For example, for an object class named Roads, the related archive class will be Roads_H.
- For optimal performance when working with the archive class, database statistics should be updated periodically based on the volume of change occurring to the archive class.
- When enabling archiving, the origin source's keyword with the prefix _ARCHIVE is searched. If such a keyword is not present, the keyword and parameter values of the data source are used.
- When you enable archiving on a nonversioned dataset, ArcGIS creates a view on the dataset that has the name <dataset name>_evw. For example, if you enable archiving on a nonversioned feature class named streets, ArcGIS creates a view on that feature class named streets_evw. If you already have a view named streets_evw, ArcGIS will drop that view. Therefore, you should rename your existing view before you enable archiving on the streets dataset.
- When working with nonversioned archiving on a multipatch, the geometry type for the archive class and preserved archive table (created after disabling archiving) are downgraded to polygon.