0

We have some integration between our Assets system and our ArcGIS 10.3.1 system. The ArcGIS SDE is versioned. The assets system uses its own version (lets call it 'Assets'), and there is another version, 'QA', that all the editors use (actually, they use their own child versions of 'QA', but lets keep it simple for now).

The assets system only integrates non-spatial attributes with the GIS features, not the geometries of features. In general, users are not permitted to change non-spatial attributes in the GIS, but only in the assets system. (This is a simplification, but will do for the purposes of this question.)

However, they can (and must) change spatial data (geometries) in the GIS.

Every night, an automated Python script reconciles and posts both of these versions to the DEFAULT version. In fact, the script runs twice every night so that the changes from each version get reconciled back to the other version, via DEFAULT.

The problem here is that if spatial data (geometry) is changed in the GIS and a non-spatial attribute is changed in the assets system on the same day, the reconcile/post will overwrite the changes in one of these (which ever gets reconciled last 'wins' and the changes in the other are lost).

The Python arcpy script uses the following line to run the reconcile/post:

arcpy.ReconcileVersions_management(workspace, "ALL_VERSIONS", "sde.DEFAULT", versionList, "LOCK_ACQUIRED", "NO_ABORT", "BY_OBJECT", "FAVOR_EDIT_VERSION", "POST", "KEEP_VERSION", reconcileLog)

(where versionList is a list of 'QA' and 'assets' versions).

I could change "NO_ABORT" to "ABORT_CONFLICTS", but that would just result in no reconcile/post occurring.

Is there any way to automatically log/notify of conflicts during this process? If set to "NO_ABORT", conflicts don't appear to be logged at all!

Even better, is there some way to automatically manage conflicts (eg, rule-based of some kind)?

Better still, when a conflict is detected between versions, is there some way to automatically retain the spatial data of the feature from one version and the non-spatial data of that feature from the other version?

  • Have you tried changing "BY_OBJECT" to "BY_ATTRIBUTE"? It's been a while since I've tested this, but I think that will only raise a conflict if the same attribute has changed – Midavalo Mar 6 '17 at 0:48
  • The documentation on "BY_ATTRIBUTE" is not entirely clear, but my understanding is that this would cause the system to not even notice there was a conflict at all (because the changes were not on the same attribute) and therefore the change would still go through and overwrite the feature from one version with the feature from the other version. – Son of a Beach Mar 6 '17 at 0:50
  • Have you tried BY_ATTRIBUTE? – Midavalo Mar 6 '17 at 0:51
2

Try changing your Conflict Definition from BY_OBJECT to BY_ATTRIBUTE

arcpy.ReconcileVersions_management(workspace, "ALL_VERSIONS", "sde.DEFAULT", versionList, "LOCK_ACQUIRED", "NO_ABORT", "BY_ATTRIBUTE", "FAVOR_EDIT_VERSION", "POST", "KEEP_VERSION", reconcileLog)

In my testing I had two versions.

  1. In Version 1 I moved a feature (but changed no attributes)
  2. In Version 2 I changed an attribute (but didn't move).

Here you can see my two versions - Version 1 (in blue) showing the new shape and original attributes, Version 2 (in green) showing the original shape and new attributes:
enter image description here

  1. I ran the Reconcile Versions tool, using the same options as you, except changing the Conflict Definition.

enter image description here

The result was my feature moved to the new location (from Version 1) and the attribute updated (from Version 2)

enter image description here

  • This does work when I tested in our dev environment. I was under the impression that this parameter only affected conflict detection, and did not affect what happened other than that. Is there anywhere that documents this behaviour? I've been unable to find it. – Son of a Beach Mar 6 '17 at 1:34
  • @SonofaBeach I haven't found documentation that says it well, however to me it didn't make sense to be able to check for conflicts by attribute, have it not raise a conflict if no attributes conflicted directly, yet still update by entire object. – Midavalo Mar 6 '17 at 1:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.