Editing the parcel fabric and versioning

This topic applies to ArcEditor and ArcInfo only.

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. If editing parcels in manual mode using fabric jobs, multiple parcel fabric jobs can be created both on the default version and on a child version.

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 in automatic mode, 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.

If editing the parcel fabric in manual mode using fabric jobs, edits are saved to the job XML stream. When the parcel fabric job is posted back to the parcel fabric (Parcel Editor > Finish Job), all edits to the job XML stream are posted to the parcel fabric as one single edit. Once the edit session is saved, a new state of the version is created.

Parcel fabric versions and edit locking

When parcels in the fabric 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, non-system 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

Edit locking in manual mode using fabric jobs

If working in manual mode using fabric jobs, the same parcel locking rules apply:

• Fabric jobs can overlap each other on the same version and on different versions. If a parcel is being edited in a job overlapping yours on the same version, the parcel is displayed with an edit locked icon in your Parcel Explorer window. When the overlapping job is closed (Parcel Editor > Finish Job), the edit lock is released and the parcel is displayed with an edit unlocked icon in your Parcel Explorer window.
• If a parcel is being edited in a job overlapping yours on a different version, the parcels being edited in the overlapping job will remain locked until the version is posted. The parcels will be displayed with an edit locked icon in your Parcel Explorer window. Once a version is posted, all jobs on the version are marked as committed and the edit locks on parcels are released. You need to reconcile your version with the default version to edit those parcels.
• 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.
• You can manually add edit locks to parcels in a fabric job even if you don't intend to edit the parcels right away. Edit locks can be added through the Create New Job dialog box when the parcel is added as an edit job parcel. Edit locks can also be added in an open job by right-clicking a parcel(s) in the Parcel Explorer window and clicking Lock Selected parcels. These parcels will be locked across versions; however, on the same version, the parcel is always unlocked when the job is closed.
• By refreshing the Parcel Explorer window, parcel lock symbols will be updated to show edit locked icons next to parcels in your job that have since become edit locked in your job.

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 non-system managed fields have changed between the default version and the child version.

Conflicts in point coordinates can occur in the following circumstances:

• A least-squares adjustment was run on the default version and on the child version.
• A least-squares 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.

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