The Duplicated Parcel Fabric
A county GIS team maintains 48,000 parcels in an enterprise geodatabase. A junior analyst loaded a new batch of 1,200 parcels from a shapefile into the Parcel feature class using the Append tool with the default schema-mapping options. Afterward, the team notices: (a) the parcel count is now 49,150, not 49,200; (b) 50 records have NULL values in the OWNER_NAME field; (c) the new features do not appear in the parcel fabric's topology, and editing them in ArcGIS Pro throws a 'feature not registered with the fabric' error. The shapefile's field names were truncated to 10 characters (e.g., OWNER_NAM vs OWNER_NAME). The geodatabase has a unique index on PARCEL_ID.
1. Diagnose the three symptoms and explain what each tells you about what went wrong during the append.
Read the worked answer
Symptom (a) - 1,200 loaded but count rose by only 1,150. A net gain of 1,150 from a 1,200-row batch means 50 rows were rejected or overwritten. Combined with the unique index on PARCEL_ID, the most likely cause is that 50 PARCEL_IDs already existed; depending on whether the analyst used 'Update and insert' vs 'Append only,' those either failed to insert (rejected) or replaced existing rows. Either way, the batch was not cleanly additive, so the analyst must reconcile against the source to confirm whether the 50 collisions were true duplicates or legitimate updates.
Symptom (b) - 50 NULL OWNER_NAME values. This is a separate, suspicious coincidence in count. The 10-character truncation (OWNER_NAM) means the source field did not map to OWNER_NAME automatically; if the analyst accepted the default field map, the target OWNER_NAME was left unmapped and populated as NULL. The fact that exactly 50 are NULL suggests those 50 rows came through a different path (e.g., the collision rows) or that only a subset was mapped. The analyst should inspect the field map rather than assume.
Symptom (c) - fabric registration error. The Parcel feature class is part of a parcel fabric; appending directly with the Append tool bypasses the fabric's registration and lineage logic. Features inserted outside the fabric's edit operations are not registered as fabric parcels, so the topology and editing environment reject them. This is the root cause that makes the whole load invalid regardless of the field-mapping issues.
2. The analyst proposes to fix everything by running Append again with corrected field mapping. Evaluate this plan and describe the correct remediation.
Read the worked answer
The plan is wrong and will compound the problem. Re-appending will:
- Hit the same PARCEL_ID unique-index collisions (now 1,150+ existing), producing another partial load.
- Insert a second set of unregistered features into the fabric, doubling the orphan count.
- Leave the original 1,200 orphaned features in place, so the count discrepancy grows.
Correct remediation, in order:
- Stop and back up - export the current Parcel feature class and the 1,200 suspect records to a file geodatabase before any edits.
- Identify the orphans - the 1,200 appended features can be isolated by OBJECTID range or a load-batch field if one was populated; if not, select by PARCEL_ID against the source list.
- Delete the orphaned features through the fabric's edit environment or by a fabric-aware delete, not a raw Delete Rows, so lineage stays consistent.
- Reconcile the 50 collisions against authoritative records - decide per record whether it is a duplicate (discard) or a correction (edit through the fabric).
- Rebuild the field map explicitly - map OWNER_NAM → OWNER_NAME, and validate every other field; do not accept defaults when names are truncated.
- Load through the fabric's supported loading workflow (parcel fabric append/load tools) rather than the generic Append tool, so features are registered and topology is built.
- Verify - recount, run fabric topology validation, and confirm zero NULLs in required fields.
The lesson: in a fabric, the generic Append tool is the wrong tool; and a partial load must be removed, not retried.