Feeder Sync has a setting in the "Configure Feeder Manager" prompt to "Enable autoupdaters during field sync". I believe this is disabled by default. With this option off, you shouldn't have to worry about AUs such as Last User and Last Update when performing a Feeder Sync, as no AUs will fire, and conflicts should be minimized.
With the option checked, AUs should be firing in a "Feeder Manager" context, so whether or not a specific AU fires will depend on which mode the AU was coded for.
Hope that helps!
The main part of my question though was about conflicts. With AUs off - or
using Esri editor tracking instead of ArcFM AUs - what would my expectation
be about conflicts resulting from the FM 2 sync. I'm presuming there
should not be conflicts in this case, but am looking for confirmation
from anyone who's actually implemented it.
On Mar 11, 2015 10:34 AM, "Corey Blakeborough" <
In the implementation I assisted with, the AU setting was turned off, and I have not heard reports of conflicts resulting from Sync being run. In this particular implementation, the Sync tool is run with GDBM for sessions and designs, with a manual sync button being used for any standalone versions.
We've run into a few instances of conflicts happening with feeder id fields in FM2, but they have all been legitimate conflicts caused by two mappers working on data cleanup tasks on the same feeders on the same day. Careful planning could have avoided this, but it's not something we would expect to see in our day-to-day operations once we get all of our data nominally fed.
Since Feeder Sync does all the operations after Post there should be no conflicts assuming the Feeder fields are not edited manually in a child version. This is with AUs off. With AUs on the likely hood of conflict increases only because child versions will be more likely to have made other non feeder edits to the features; however, overall conflicts will be reduced by FM2 substantially.
Is there any reason you would want AUs to fire on sync? I would think a 'state' change on an object would not justify an AU execution as would a 'property' change, unless you have some logic driven by Feeder ID or INFO at the AU level.
No, I wouldn't want AUs to fire on FM 2.0 feeder sync. I was even a
little surprised this would go through ArcObjects and not simply perform
the edit though a multi-version view.
But I guess going thru AO gives the option if someone wants it.
Reason for my original question was that I heard concern expressed about
increased possibility of conflicts with feeder sync and was looking for
actual, real world experiences.
Thanks much for the info.
On Mar 12, 2015 7:23 AM, "James Wright" <