Sync Framework Dilemma

MarkCederholm — Thu, 10 Nov 2016 16:52:40 GMT

We've been running into a problem with the sync framework, but it's not a really bug, rather a locking issue. The problem is, originally the sync framework only supported non-versioned feature classes, and when people are editing those feature classes back in the office, it blocks synchronization attempts (as ArcGIS Server logs so painfully reveal). Recently, we started experimenting with a sync-enabled service with versioned feature classes, and upon discovering how that mechanism actually works, realized that this could lead to a data management NIGHTMARE.

Has anyone found a happy solution? I'm thinking possibly that, via a script, we could transfer new features from a field class to a back-office class for further editing. The problem there is that the updated data needs to get back out into the field. Perhaps the feature service should point to a two-way replica of the back-office class which is synchronized nightly? I can't help but feel that this is more complicated than it needs to be.

Any ideas? Success stories?

Update: It just occurred to me that, in Esri's flashy demos, maybe the back-office people are editing via the same feature service rather than using ArcMap. That might be an alternative worth investigating.

topic Sync Framework Dilemma in .NET Maps SDK Questions

Sync Framework Dilemma