Version Reconciliation Turns Twenty-Two Valve Records Back in Time
Ridgeline Water Authority runs an ArcGIS Enterprise geodatabase on SQL Server. Its 260,000-polygon Parcel feature class and its Valve point feature class are versioned and archivable. Twelve technicians each create a personal version from DEFAULT and edit for two to three weeks before reconciling. A nightly Python job creates a version named QA_, copies the day's QA edits into it, reconciles and posts it to DEFAULT, and deletes nothing. Last month a technician finished a version holding 340 valve edits and 1,200 parcel attribute updates. She reconciled with DEFAULT, accepted every conflict in favor of the edit version, and posted. The next morning the asset manager reported that 22 valve records had reverted to values entered by a different crew ten days earlier, and that reconciling a fresh version now takes 35 minutes instead of 2. The geodatabase has grown from 40 GB to 190 GB, and compress has failed every weekend since March.
1. Explain how the 22 valve records were overwritten and describe the reconcile/post discipline that prevents a recurrence.
Read the worked answer
What happened. Reconcile compares the editing version with the target at their common ancestor state, then applies the editing version's changes onto a copy of the target. A conflict exists wherever the same row or attribute changed in both lineages since that ancestor. Her version was three weeks old, so every valve another crew had touched and posted in the interim appeared as a conflict, and choosing 'in favor of the edit version' wrote her now-stale values over the newer ones. If resolution was done at attribute level for the whole feature, she may also have replaced attributes she never intended to touch.
The discipline.
- Keep versions short-lived: reconcile with DEFAULT daily and post weekly, so conflicts surface while the editor still remembers the work.
- Reconcile, read the Conflicts list, and resolve object by object or attribute by attribute. Use the bulk 'in favor of the edit version' option only after confirming that version is genuinely the newer authority.
- Reconcile once more immediately before posting. A post is only valid against the target state you actually reconciled with; anything posted in between is not re-evaluated.
- If two-week edit cycles are unavoidable, move to branch versioning published as a feature service, where each save is applied to current state and long-lived conflicts stop accumulating.
2. Reconcile has degraded from 2 minutes to 35 minutes and compress fails weekly. Diagnose the cause and give an ordered remediation plan.
Read the worked answer
Diagnose the version tree first. In the Versions view, or with arcpy.da.ListVersions, check lineage depth and owners. Two things are almost certainly true: dozens of QA_ versions still exist, and some were created from each other rather than from DEFAULT, so every reconcile walks a long state chain.
Order matters.
- Reconcile and post every legitimate version, then delete every obsolete QA version. Compress cannot trim states that a version still references, which also explains both the 190 GB and the repeated compress failure.
- Run compress in a maintenance window with no editors connected; it rewrites the delta tables and drops unreferenced states.
- Rebuild indexes and update statistics on the base and delta tables afterward.
- Fix the QA job so it creates one version from DEFAULT each night and deletes it after posting. Never chain versions.
Do not forget archiving. Archive-enabled datasets keep history separately from versions, so archive growth will continue even after compression. Confirm the retention policy against the records requirement before you trim it; otherwise you will fix the size problem and destroy the audit trail in the same change.
3. A reviewer asks what the valve records looked like on 12 March. Describe how you would produce that answer and the checks that must pass first.
Read the worked answer
Verify archiving predates the date. Versions are not a time machine. If archiving was enabled on 20 March, the 12 March geometry cannot be recovered from versions. Check the dataset's Archive-enabled state and the archive retention before promising anything.
Historical version route (traditional versioning). Create a historical version with arcpy.management.CreateVersion against the parent and supply the historical date, or use the Versions view and specify the moment. Connect using that version, add the valve layer, and export or compare. Historical versions are read-only, present the database exactly as of the moment, and should be deleted when finished so they do not accumulate as another lineage.
Branch versioning route. There are no historical versions. Query the feature service with a historic-moment/as-of parameter instead, which depends entirely on archive history being retained.
Caveats to state in the answer. Archived rows live in the __H table with gdb_from_date and gdb_to_date; filtering only the feature table gives current attributes joined to old geometry and silently produces wrong results. Confirm 12 March falls inside retention, and confirm no replica or offline copy of the data was used to republish the layer after that date, which would have replaced rows without normal version lineage.