Editing the parcel fabric and versioning

Available with Standard or Advanced license.

The parcel fabric supports editing on one version level below the default version. The parcel fabric does not support editing on child versions of versions.

Editing the parcel fabric and version states

The parcel fabric needs to be registered as versioned before it can be edited on an ArcSDE geodatabase. Once a parcel fabric is registered as versioned, you can create a version to edit the parcel fabric. Versions are a sort of view of the geodatabase that allows you to edit that view and immediately see your changes. Other users connected to the version will see your changes when you refresh. However, users connected to other versions will not see your changes until you post your version to the default version.

When a dataset is registered as versioned, two delta tables are created: the A (or Adds) table for inserts and updates and the D (or Deletes) table for deletes. Each time you update or delete a record in the dataset, rows are added to one or both of these tables and a new state of the version is created. A versioned dataset, therefore, consists of the original table (referred to as the base table) plus any changes in the delta tables.

Learn more about versioning

When editing parcels, each edit is made to a job XML stream. When the edit session is saved, the XML stream is posted to the parcel fabric as a single edit and a new state of the version is created.

Parcel fabric versions and edit locking

When parcels are edited, they become edit locked. When a parcel is edit locked, it cannot be opened on the same version or another version until the edit lock is released. However, in the locked parcel's attribute tables, nonsystem managed fields in the parcels, lines, points, and control tables can still be edited. If the same field is edited across different versions, conflict resolution will be required when the versions are reconciled.

See which fields are editable in a locked parcel's attribute tables.

If parcels are being edited on a different version from the one you are editing, those parcels are displayed with an edit locked icon in the Parcel Explorer window. Likewise, the parcels you are editing will be locked from edits in any other versions. Parcel edit locks are released once the version on which the parcel was being edited is posted.

The list below summarizes the rules governing the behavior of locked parcels in a multiuser environment:

• You cannot open parcels being edited in another version. You can only gain access to edit locked parcels from another version once that version is posted. When a version is posted, all updates and changes in the version are merged with the default version and edit locks on parcels are released.
• If a parcel has previously been edited on the version you are working with, the parcel is displayed with an edit unlocked icon in the Parcel Explorer window.
• If a parcel has previously been edited on another version that is now posted, the parcel is displayed with an edit unlocked icon in the version you are working with.
• If parcels have been edited in a different version and that version has been posted to default, you can edit those same parcels in your version once you reconcile with the default version.
• If a parcel is listed as locked in the Parcel Explorer window, you can click the parcel in the Parcel Explorer window to see which version and user are editing the parcel. The user and version name are displayed in the bottom right status bar of the ArcMap window.

Summary of edit lock status icons

	Parcel is available for editing.
	Parcel is currently being edited.
	Parcel has been previously edited and is available.
	Parcel is being currently edited on the same version or has been edited on a different version.

Summary of edit lock status icons

Reconciling versions and the parcel fabric

Once you have finished editing on a version, you can merge the changes made on the version with the default version. This is done through a reconcile and post process. Reconciliation detects conflicts between your version and the default version. Conflicts occur if the default version has changed since you created your version and the changes conflict with your edits. For example, on a parcel fabric, least-squares adjustments run in overlapping areas will produce conflicting coordinates. Conflict resolution on the parcel fabric always takes place in favor of the child version.

Note:

The parcel fabric jobs table is not a versioned table and thus is not subject to reconciliation on parcel fabric versions.

Learn more about reconciling versions

Frequent reconciling of versions with parcel fabrics against the default version is recommended. When a child version is reconciled with the default version, the child version receives any updates that have since been posted to the default version from other child versions.

Edits and updates to parcel data are typically in the form of long transactions. In the parcel fabric, parcel edits can span long periods of time. Reconciling versions will update versions with new and current data from the default version. This is important for continued editing of a versioned parcel fabric.

The following lists some examples of updates that could be received when reconciling a versioned parcel fabric with the default version:

• Updated coordinates for parcel points (least-squares adjustment run on the default version or posted from another version)
• New parcels created on the default or posted from another version
• Updated or new control points created on the default or posted from another version

Conflict resolution

When reconciling a version with a parcel fabric against the default version, conflicts will be detected in these cases:

• Point coordinates have changed between the default version and the child version.
• Attribute values in nonsystem managed fields have changed between the default version and the child version.

Conflicts in point coordinates can occur in the following circumstances:

• A parcel fabric adjustment was run on the default version and on the child version.
• A parcel fabric adjustment was run on the child version being reconciled and on another child version that has been posted to the default.

In the parcel fabric, coordinate conflicts are always resolved in favor of the latest set of adjusted coordinates. Thus, when reconciling a child version that has been adjusted, the following are true:

• Adjusted coordinates in the default version versus adjusted coordinates in child version: child version wins.
• Conflicting control point coordinates are resolved in favor of the child version.

Posting versions and the parcel fabric

When a version with a parcel fabric is posted, all edit locks to parcels are released. If there are jobs created on the version, the job status is changed to Committed. A committed job can be deleted from the job book. A committed job cannot be reopened, but the job properties, such as what parcels were used in the job, are still visible.

To pan and zoom to a committed job, you need to add the following empty BLOB fields to the jobs table:

• CommittedObjs
• LocalControl

Once these fields are present in the jobs table, you will be able to zoom and pan to parcels of committed jobs.

Note:

If there are active jobs in the parcel fabric job book on the default version, these jobs need to be committed before reconciling and posting child versions. Active jobs on the default parcel fabric version will prevent the reconciliation and posting of child versions. The status of each job is displayed under the Status field in the Job Book dialog box. To commit a job, add the Commit Job command located under the Parcel category under the Commands tab on the Customize dialog box. Select the job and click the Commit Job command to commit the job and release the edit locks. The Customize dialog box can be opened by clicking Customize > Customize Mode.

Permissions, versions, and the parcel fabric

When a parcel fabric is created within a versioned database environment, the permissions granted for the parcel fabric and for any database version in which parcel edits might take place need to be considered carefully. This is because processes enacted on the version, such as reconciling or deleting the version, could trigger processes on the parcel fabric. Since the permissions granted on a version are independent from those on a parcel fabric, a user could have permissions to reconcile, post, or delete a version without having permissions to edit a parcel fabric contained within that version. Where such a permission mismatch occurs, either the version operation would fail (reconcile and post version) or the parcel fabric data would be compromised in some way (delete version).

Any multiversion system containing a parcel fabric must be set up such that the following statement is always true: Any user performing an operation on a version that affects a parcel fabric within that version must have update permissions on that parcel fabric and any associated feature classes.

Note:

When applied to the version, the term permission is used to describe users' access; when applied to tables and datasets within the database, the term privilege is used.

Version permissions

A version can be created with one of three permission settings. These act in addition to the privilege settings on the individual datasets; for example, a user can only edit the features of a dataset within a version if he or she has update capability on both the version and the dataset itself.

These are the three permission settings:

• Private: Only the version's owner can view and edit the datasets within the version. Only the version's owner can perform operations on the version (such as deleting and reconciling).
• Protected: Any user can view the datasets within the version, but only the version's owner can edit them. Only the version owner can perform operations on the version.
• Public: All users can view and edit datasets within the version. All users can perform operations on the version.

Privileges and parcel fabrics

Each parcel fabric must be created within a feature dataset. The owner of the fabric automatically has update privileges. Other users can be granted privileges for the parcel fabric by changing the privileges on the feature dataset containing the parcel fabric. In this way, parcel fabrics behave exactly like other feature classes contained within feature datasets.

For feature classes that are not created within a feature dataset, privileges can be granted for specific users directly on that feature class.

The privileges that can be granted on a particular dataset are as follows:

• None (default): The user cannot view or edit the dataset.
• Select: The user can read and query the dataset.
• Select, Update, Insert, Delete: The user has full read/write privileges on the dataset.

Types of edits in the parcel fabric

Parcel fabric edits take two forms:

1. The parcel fabric classes themselves (for example, parcels, lines, and control points) can be edited via Parcel Editor.
2. Other feature classes can be associated with the parcel fabric. The system can then be used to propagate the results of least-squares adjustments to these feature classes, thereby editing their geometries.

In the first case, the user performing the edits must have update privileges on the feature dataset containing the parcel fabric being edited. In the second case, the user must have update privileges on both the parcel fabric and the associated feature classes.

It is not necessary to have update privileges on a parcel fabric or its associated feature classes if no edits have been made to the parcel fabric or to any feature classes associated with the parcel fabric within the version being reconciled, posted, or deleted.

The graphic below summarizes the permissions and privileges that must be granted to a user performing an operation on a version where the parcel fabric and its associated feature classes have been edited in either the parent version or the child version being considered.

Parcel fabric permissions and privileges

Feedback on this topic?