Home    |    Concepts   |   API   |   Samples
Concepts > Versioning > Basic Principles
Practice of Versioning

Each version in ArcSDE represents a unique, seamless view of the database, distinguished from other versions by a particular set of edits made to that version since it was created. Versions differ only in the number of rows that represent each database object (table), taking into account any new, modified, or deleted features or rows. The schema of each versioned database object is identical across all the versions; any supported schema changes made to a dataset—for example, adding a new field to a table—will appear in all versions of the geodatabase.

To enable versioning on a dataset, it must first be registered with the geodatabase. When a new feature class or table is created using the desktop applications or some custom ArcObjects® application code, this registration happens automatically. Tables created by third party application software (not ArcGIS tables), must be registered with the geodatabase manually.

This process registers the dataset in the geodatabase system tables and adds a unique integer field, the ObjectID (OID) field, to the dataset: versioning relies on the presence of this field. Once a dataset has been registered with the geodatabase, it can then be registered as versioned. Once registered as versioned, the dataset will participate in all versions of the database. If the dataset is edited in a number of versions, each version will represent an alternate view of the same dataset. A geodatabase can contain both versioned and unversioned data.

Internally, versioning is managed by a number of DBMS tables. The tables are an addition to the ArcSDE data storage schema objects, the business or base table, feature and spatial index tables, and so on. For more details on tables used for managing versioning, see the Database Schema section.


feedback | privacy | legal