An overview of editing versioned data using SQL

To edit data that is registered as versioned (traditional) from a SQL client, you must edit a versioned view of the data, not the base (business) table itself. Traditional versioned tables use two associated tables—the adds and deletes tables (collectively referred to as the delta tables)—to record changes. When you edit a versioned view of the table, edits are written to the adds and deletes tables. Editing the base table directly circumvents this and could lead to orphaned records and data loss.

When you execute SQL data manipulation statements against a versioned view, the following takes place in the database for each type of statement:*

• Insert: A row is added to the adds table of the underlying base table, and an object ID value for the new row is automatically generated.
• Update: Update essentially deletes the original row and adds a new one that contains the new information. Therefore, a row is added to both the adds and deletes tables of the underlying base table when you execute an update statement.
• Delete: A row is added to the deletes table of the underlying base table.

*If editing the Default version when it is pointing to state 0, all edits are immediately moved to the base table.

Be aware that no internal version reconciliation is done for edits performed through SQL. Therefore, you must reconcile your edits with a parent version through ArcGIS Desktop or a Python script after you have finished editing.

Editing options

You can create a new, named geodatabase version and edit that version, or you can edit the Default version directly. Which one you do depends on the requirements at your site. It is important to choose the appropriate model—either editing a named version or editing the Default version—to ensure optimal performance and scalability.

Edit a named version

You would create and use named versions to edit with SQL through versioned views if any of the following is true at your site:

• Multiple editors must change the same data.
• You require a well-defined quality control process.
• The changes do not have to be immediately available to other users; rather, they can be kept separate until you reconcile and post them.
• The versioned feature classes you want to edit use a binary geometry storage type.
• The versioned feature class or table you want to edit is registered as versioned with the option to move edits to base.

When you edit through a versioned view, edits are recorded in the adds and deletes tables. The edits are written to the state the named version currently references.

The steps you take to edit data in a named version are as follows and should be performed in the order shown:

1. Create a versioned view on a versioned table or feature class if one does not already exist.
2. Create a geodatabase version in which to do your edits.
3. Use the set_current_version procedure to specify that you want to access your new version. Doing so sets the edit session to the state the named version is pointing to and locks the version.
4. Start an edit session by executing the edit_version procedure or function appropriate to your database.
5. Perform your edits on the versioned view using SQL.
6. Commit your edits to the database or roll them back.
7. Stop the edit session by executing the edit_version procedure or function appropriate to your database.
8. Reconcile and post your edits through ArcGIS.
9. When all changes are posted to a parent version using ArcGIS, you can delete the version you created for your edits on the versioned view.

Edit the Default version

You could edit the Default version with SQL through versioned views if one or more of the following are true at your site:

• The edits to be made are short transactions.
• Your site requires that the edits made through a versioned view be available to other users immediately.
• If editing feature classes, the feature classes use SQL spatial types, not binary geometry storage.
• The table or feature class to be edited is not registered as versioned with the option to move edits to base.
• The data you will be editing is not replicated. If you edit the Default version of replicated data, edits will not be synchronized.

When you edit the Default version, edits are recorded in the delta tables just as they are when you edit a named version. However, when you edit the Default version, the edits can be seen by anyone viewing the Default version.

If the Default version references state 0, each edit is applied directly to the base table of the versioned table or feature class. When the Default version is edited with an ArcGIS client, the version is updated to reference a new database state upon saving. When a versioned view edits Default directly, each insert, update, and delete operation is written to the current state the Default version references.

For example, if the Default version is updated with an ArcGIS client while multiple changes are being performed through the versioned view, it is possible that the changes made through the versioned view can be applied to multiple states.

Once your edits are committed, they are immediately accessible to the following:

• Users or applications that are working with the versioned table and the Default version
• Users or applications that are working with a child version that has a state lineage that contains the Default version's current state

Dive-in:

If the row being modified in the Default version by a versioned view has been modified by another version in a state that is dependent on the Default version's current state, the versioned view creates a new geodatabase state, updates the Default version to reference the new state, then performs the edit. This is required to ensure that the row being modified (which is also modified in a state dependent on the Default version's state) will not be overwritten by a compress operation or when the descendant state's version is reconciled with the Default version.

You do not set the version or start an edit session if you want to edit data in the Default geodatabase version through a versioned view. The steps you do perform are as follows:

1. Create a versioned view on a versioned table or feature class if one does not already exist.

   Note:

   If the versioned view was created prior to ArcGIS 10.1, you must re-create it; older versioned views cannot be edited in the Default version.

2. Perform your edits on the versioned view using SQL. You will automatically be editing the current state of the Default version.
3. Commit your edits to the database or roll them back. It is best to commit or roll back after each edit because, while your transaction is open, exclusive locks are held on the delta tables. The locks are not released until the transaction ends.