This post summarizes a discussion we initiated on the Schneider Electric Exchange Community site on expectations a user might have for versioned conflicts arising from implementation of the ArcFM Feeder Manager 2.0 Synchronization process.
First a little background
ArcFM Feeder Manager (1.0) dynamically maintains feeder information through the course of editing operations – including switching changes. This is critical information for maintaining integrity of an electric system model. The result of the process is that a value is stored in the FEEDERID field of all features participating in the electric network.
Storing the value in the FEEDERID field can take some time and also result in version conflicts, so SE built Feeder Manager 2.0 which discovers feeder ID values when needed by the application and uses a separate memory structure to hold feeder ID values. The result is a dramatic improvement in some editing operations and elimination of conflicts resulting from feeder updates. And, there is no need for a FEEDERID field on network classes.
However, while there is a lot to like about FM 2.0, some users need a FEEDERID field – in many cases to support legacy applications such as interfaces to operations or asset management systems. To meet this need SE created a “Feeder Sync” process that stores the FEEDERID value – but does it in a way that doesn’t affect user editing performance and *should* minimize version conflicts.
This is where our post picks up
The question is, “are we in danger of introducing conflicts by using the FM 2.0 Feeder Sync?” And, as in many cases, the answer is, “it depends.”
Here’s why. The FM 2.0 Feeder Sync makes updates to FEEDERID fields directly in the SDE.DEFAULT version and, by configuration, can operate either with AutoUpdaters in effect or not.
Here’s a scenario in which the FM 2.0 Feeder Sync would likely generate conflicts – and probably many of them.
- Implement FM 2.0 Feeder Sync with AutoUpdaters enabled and use the “ArcFM User Name” and “ArcFM Current Date” AU’s. (These are sometimes referred to as “meta-data AutoUpdaters”.)
- Reconcile child version with SDE.DEFAULT – using either row level or field level conflict detection. Conflicts will be detected on LAST_USER and/or DATE_MODIFIED fields in any case where a feature in the child version was changed and the FEEDERID updated in SDE.DEFAULT.
In contrast, the following scenario will only result in conflicts if the same value on the same feature was changed in SDE.DEFAULT and a child version (a “true” conflict):
- Implement FM 2.0 Feeder Sync with AutoUpdaters disabled.
- Reconcile child version with SDE.DEFAULT – using field level conflict detection. Conflicts will result only where the same field was updated in both versions. And since FEEDERID is updated only in SDE.DEFAULT there will be no conflicts on FEEDERID.
In addition, this scenario should also void all but “true” conflicts:
- Implement FM 2.0 Feeder Sync with AutoUpdaters enabled with ArcGIS Editor Tracking used to maintain meta-data information instead of the “ArcFM User Name” and “ArcFM Current Date” AU’s.
- Reconcile child version with SDE.DEFAULT – using field level conflict detection. Conflicts will result only where the same field was updated in both versions, and may include any updates resulting from non-meta data AutoUpdaters.
Depending on your work flow and requirements the FM 2.0 Sync process could result in many unwanted conflicts. However, if you don’t need AutoUpdaters firing during the sync process or are using ArcGIS Edit Tracking instead of the ArcFM meta-data auto-updaters then these conflicts can be avoided.