ArcGIS Mobile rules or constraints applied in sync process

Idea created by ESandinesriaustralia-com-au-esridist Employee on Sep 14, 2012
    • joabelb
    ArcGIS Mobile should support rules or constraints as part of the sync process.  The rules should be applied so that incoming edits that violate the rules at sync time will be rejected without breaking the Mobile sync process. A detailed description of one business case may be found below.
    We are experiencing an issue where we have multiple users who perform attribute editing on the same particular feature during the course of the day. To start, we are using ArcGIS 10, ArcGIS Server 10 and ArcGIS Mobile 10 as our field editing software and are using a non-versioned transaction model. The workflows we use consist of individual work crews updating 1 particular field in a feature to update the status of that feature according to the work they performed. So, crew 1 updates the feature from status 'A' to status 'B' and later in the day, crew 2 updates the same feature to status 'C'. The correct status for the feature is now 'C' due to crew 2 updating after crew 1. In a connected environment, we have no issues with this scenario as the auto-post and auto get data procedure we have configured on the devices ensures the most up to date features are present most of the time. When, however, we are in a disconnected environment, both crews are storing their edits on their devices and then upload when they reach a 3G area. The issue arises if crew 2 uploads before crew 1, the incorrect status is reflected in the feature as the edits are committed on a first come, first serve basis rather than being identified by edit time. We need to setup a procedure that will allow edits that are being committed to the database to be checked for their edit time against the last edit commit time on the database to then be able to reject the edit if it was collected prior to the last edit that was committed to the database? I know versioning allows us to manually do this using desktop on an edit by edit basis however we really would like this to be an automatic process running on the database and evaluating the edits dynamically at actual commit time. We also cannot use versioning as our editing environment has been proven to not be suitable for this particular transaction model.