The dirty objects table is a system-maintained table used to store information about edits made to nonspatial objects and associations in a telecom domain network. This table is created when the first telecom domain network is added to your utility network. When a nonspatial object or association in the telecom domain network is modified, a row is created for each in the dirty objects table. This additional table is used with nonspatial objects in a telecom domain network due to the use of foreign-key fields to manage certain association types instead of using the Associations table.
Beta:
The telecom domain network is available as beta functionality through the Early Adopter Community in ArcGIS Pro 3.5 and ArcGIS Enterprise 11.5, as a result some links may not be active. To access this functionality and learn more, join the Telecom Domain Network Early Adopter Community.
The dirty objects table can be accessed as a subtable of the utility network from the Contents pane of an active map.
Each row in this table represents the status of edits made to nonspatial junction objects, edge objects, and associations in the telecom domain network. When the object is locatable, a dirty area is also created for the first spatial feature in the containment hierarchy which allows you to validate the network topology for edits in the current extent.
The dirty objects table stores information about the following:
- Whether nonspatial objects and associations have been modified or are in error in the telecom domain network.
- Information about the objects that participate in an association.
The dirty objects table contains the following attributes:
| Field name | Field alias | Description |
|---|---|---|
OBJECTID | Object ID | The object ID for the record in the table. |
SOURCEID | Network Source ID | The network source for the dirty object in the utility network. |
GUID | FeatureGuid | The global ID of the object or association represented by the dirty object. |
STATUS | Status | The Status field value is used to communicate how the dirty object was created. |
ERRORCODE | Error code | Errors on dirty objects are displayed using a bit encoded value that can represent one or more errors. |
ERRORMESSAGE | Error message | Additional contextual information associated with the error. |
CLUSTERKEY | Cluster key | Attribute which optionally enables improvement of object clustering in the network topology. |
CREATIONDATE | Creation date | The date the dirty object was created. |
CREATOR | Creator | The user who created the dirty object. |
LASTUPDATE | Last update | The last time the row in the table was updated. |
UPDATEDBY | Updated by | The last user to update a row in the table. |
GLOBALID | Global ID | The global ID of the row in the table. |
Interpret Status field values
The Status attribute field value indicates what type of modifications have been made to an object or association participating in the telecom domain network. The values displayed in the attribute field represent decimal values that correspond with a bit encoded value. The following table outlines the status bit values and how these are presented in the Status field:
| Status bit | Status field value | Description |
|---|---|---|
N/A | 0 | The object or association is not dirty or deleted. |
0 | 1 | Inserted or updated object or association |
1 | 2 | The object or association is deleted. |
2 | 4 | The object or association is in error. |
3 | 8 | The circuit is in error. |
Validate dirty objects
Validating the network topology maintains consistency between what you see on the map and what is present in the network topology. Associations with spatial features are used to determine the location of, and visually represent, nonspatial objects on a map. The locatability of nonspatial objects is important because spatial features provide a mechanism to create dirty areas and validate edits.
When a locatable object, or an association with one, is created or modified, a dirty area is created for the first spatial feature in its containment hierarchy. With telecom domain networks, dirty objects are validated through these dirty areas. Analytic operations rely on the network topology and thus may return unexpected results if dirty areas or objects exist. No dirty areas are created as a result of edits made to an object that is not locatable. As a result, these edits are not reflected in the network topology. Geometry and network attribute edits made to unlocatable objects require you to disable and enable the network topology to reflect the changes.
Reconcile and post dirty objects
When a version is reconciled, it will inherit the current state of the network topology from the default version. Dirty objects are then re-created for all objects, and dirty areas are re-created for the associated features edited in the named version that resulted in a dirty object being created. Validating dirty areas and objects inherited by the version during reconcile allows you to continue work in a version but will prevent posting until the version is reconciled again. When these dirty objects are posted, this allows the topology for these modified features to be validated and rebuilt in the default version.