Working with representations in a versioned environment
Release 9.2 Last modified August 15, 2007	Print all topics in : "Working with representations"

To understand how representations work in a versioned environment, it is important to first have a solid understanding of the principles of versioning and of how feature class representations are stored inside the geodatabase.
Learn about versioning
Learn about how representations are stored

How do representations work in a versioned environment?

Feature classes with representations participate in a versioned environment much the same as feature classes with no representations. Here are some key things to consider:

• Creating representation is a schema change.
  
Since schema changes cannot be versioned, a representation added to a versioned feature class will be visible in all versions. Similarly, removing a representation from a feature class will be reflected in all versions. Representations can only be created outside an edit session.

• Changing a representation rule is a schema change.
  
Any changes to the structure, the property values, or the field mappings of a representation rule is a schema change and will be reflected in all versions immediately. Representation rule information is held in the non-versioned GDB_ExtensionDatasets table, so it is persisted across the database. Representation rules can only be changed outside an edit session.

• Applying representation rules to features is an attribute change.
  
Representation rules are applied to features throught the Rule ID field. Applying a different rule to a feature—or setting a feature to a null rule—is an attribute change. It will only be reflected in the current version. Conflicts can be resolved using standard reconcile and post procedures.

• A shape override is an attribute change.
  
Shape overrides will only be reflected in the current version until reconcile and post is performed.

• Overriding a property of a representation rule is an attribute change.
  
Overrides will only be reflected in the current version. Conflicts can be resolved using standard reconcile and post procedures.

• Converting a feature representation to a free representation is an attribute change.
  
The process of creating a free representation will trigger a change in both the Rule ID field and the Override field. The Rule ID value is always -1 when a feature representation is a free representation.

Best practices

• Why is a column-level conflict raised when I override two different properties of a feature in two different versions?
  
Confusion can occur when two separate properties are overriden in two different versions. A conflict will be raised if both overrides are stored in the Override field, which is the default storage location for all overrides.
For example, a feature follows the Cart Track rule in version 1 and version 2. In version 1, the line width of the cart track symbol has been overriden for that feature. In version 2, only the color of the cart track symbol for that feature has been overriden, but the line width feature still follows the rule. Since both changes are held in the Override field, a conflict would be raised in reconcile using both row-level and column-level conflict resolution, even though the changes are not truly in conflict.
To avoid this situation, a better practice is to map those properties that you are likely to be overriding to explicit fields. This will separate the changes into unique fields so that they won't be detected by column-level checking.
Learn more about explicit fields

• I have a large production database with many versions and a long lineage. Do I have to unregister the feature class as versioned before I enable representations?
  
Creating new feature class representations will add two new fields—Rule ID and Override—to the feature class table in all versions. If you made the representation by converting a symbolized layer, the Rule ID field will be populated in the current version only. The feature class representation itself will appear in all other versions, but the Rule ID values in those versions will all be Null. In this case, it can be cumbersome to update the Rule IDs across all versions of the database. If your workflow permits, create representations prior to registering your database as versioned. This will be faster than creating representations on a versioned feature class, because the delta tables do not have to be populated. If all edits are posted to the DEFAULT version—or the database has been compressed to preserve edits—then unregister the data as versioned prior to creating new feature class representations.

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.