Automated Reconciliation with arcpy re-identifies conflicts that have already been manually resolved

03-27-2020 12:36 PM
New Contributor III

Running into issues automating version reconciliation using arcpy script scheduled nightly on Windows Server.  ArcGIS Desktop 10.6.1 Enterprise Geodatabase (SQL Server) with multi-generation version tree (3+).  Believe Windows and SQL Servers are 2016, but cannot confirm at this time.


Would like to automatically RECONCILE ONLY all versions nightly as maintenance step before Compress. Reconcile will identify conflicts and notify version owner who will manually resolve the following day.  We only want to resolve unique conflicts one time while the version exists and until new (not already resolved) conflicts are generated.  Want to avoid having to resolve the exact same conflicts every day.

Reconciling with arcpy.ReconcileVersions_management(): by attribute, no post, abort on conflict.

Versions can exist from days to weeks as needed.

All Edits are manually reviewed and posted as needed. 

Versions are deleted after posted to parent as long as other child versions do not exist. 


Starting to think that the automated behavior I want is not possible, but if anyone else has run into this issue and figured out a workaround, would appreciate some advice because I am out of ideas.  Please read on for more detail...



Initially reconciled all versions with DEFAULT, then realized I was unintentionally creating conflicts.  Thought (incorrectly) it might have to do with the order of reconcile decided by the EGDB, so came up with a way to control for that.

Controlling reconcile order by first generating a list of versions with children sorted by parent version creation date (top down - oldest first, newest last).  Oldest version reconciles with its children.  Those children then each reconcile with their own children, and so on...




Legitimate conflicts identified by automated script are reviewed and resolved by editors the following day. Automated script then re-identifies same (and potentially new) conflicts on the next run.

This is not exactly* how the reconcile / identify conflict / resolve process works manually using the Reconcile Tool on the Version Manager Toolbar in ArcMap.  Once an editor identifies and resolves a conflict with its parent and then saves the edit the same conflict will not be identified the next time the editor reconciles their version with its parent. 

* Difference is that the editor can only reconcile with the parent version using this tool, not with grandparents, great-grandparents, etc.. as is happening in my script.




Illegitimate conflicts identified by automated script if the child edits same record as parent version. 

Again, this is not exactly* how the reconcile / identify conflict / resolve process works manually using the Reconcile Tool on the Version Manager Toolbar in ArcMap.  A child version can edit the same record as its parent without generating a conflict, it is just a standard version change. Which brings us back to ISSUE #1.



- Analyst creates a new version off DEFAULT, makes an edit (adds a new polygon based on valid dimensions in approximate location) and notifies Manager to review edit.

- Manager creates a child version of Analyst's edit version and makes correction (moves new feature to correct location). 




I understand that I am triggering these conflicts by starting at DEFAULT (oldest version) and reconciling down generationally.  No matter how I think about it though, I simply cannot wrap my head around reconciling (no post) from the bottom up.

I did test the bottom up approach though... after conflicts were manually resolved, the automated script did not generate conflicts on the next automated run, but (as expected) conflicts were again identified as described above on the next run.

I get that technically these are all “conflicts” by definition, the same record was edited in multiple versions, but once they are resolved they would (ideally) not need to be addressed again.

I can also see the argument "how would the database know" that subsequent conflicts are/are not the result of the exact same edit.  I feel like this scenario could be better handled by reviewing the Version Change log or whatever QA/QC process is in place at the organization. 

My assumption is that conflicting records are determined on the fly when the reconcile tool runs and records of conflict resolution are not stored anywhere in the geodatabase tables for subsequent runs to refer to?

IF the answer is simply ESRI Versioning doesn’t work this way, then good to know not to put any more effort into this rabbit hole. 



If anyone else has encountered similar reconcile automation issues or if anyone notices a flaw in my logic or process... 

Please reach out to me, would really like to figure out a better way if possible. 


Thanks in advance!

0 Kudos
1 Reply
Esri Frequent Contributor

Geodatabase‌ - for a broader audience.

You also may want to contact technical support and work with a Geodata specialist on this.

--- George T.
0 Kudos