Latest Contributions by EdwardBlair

We are deploying an application that is leveraging sync-enabled feature services to update mobile geodatabases on user client machines.  We've had to work out some kinks with mobile gdb registration and synchronization, but things seem fairly stable at this point. Our current concern is about tracking what user has synchronized when.  There will be hundreds of mobile users, each of whom will be synching at different points in time.   From an admin standpoint we want to know which users have data that is up-to-date and which users do not -- actually we mostly want to know about those that do not. We've considered some, admittedly kludgy, ways to do this -- like by adding a single, special purpose feature to each class or table that has the last sync table for each class.   But it seems there should be information available from the parent replica database about which client has synced when. Any suggestions on how we might access replica sync history would be much appreciated. Thx, Ed ... View more

We are working with a mobile solution vendor that relies on ArcGIS sync-enabled feature services to replicate enterprise data to mobile devices.  The services all reference non-versioned, archive-enabled feature classes in an enterprise Geodatabase.  We're following the 'pre-planned' model where we create the initial 'golden' mobile geodatabases on the server and distribute these initially to all clients.  The first time a mobile user connects to the server it is supposed to be 'registered' with the enterprise - obtaining a new replica ID that will subsequently be used to determine what enterprise updates need to be propagated on later "synchronize" events. Many, maybe even most times the initial registration task will succeed.  Unfortunately, we've found that in a noticeable number of cases the registration does NOT succeed, meaning that subsequent synchronization will not occur.  This is bad. It seems that once registration has failed, further efforts at registration will also fail.  We haven't seen any pattern for registration attempts that fail versus attempts that succeed -- not to say there aren't any, we just have not seen them. The vendor says they cannot replicate the issue.  No comment warranted here. Comments from anyone has experienced this, or knows anything of this behavior, would be greatly appreciated. Thx, Ed ... View more

We step up replication from a versioned production Geodatabase into versioned replica about a month ago.  We haven't synchronized for several weeks.   There have been thousands of edits performed in the interval.  When we just recently performed a sync only a handful of features were copied to the replica.  Based on a CREATED_DATE field we can easily see that some classes were not moved at all. When we set up the replica we had a DBA make a new Oracle instance and load a backup from production, so on creating the replica we simply registered all the classes - and we made sure all classes were registered. So, the question is, what could make the sync send only a handful of features when we expected many? Any insights would be much appreciated. Thx, Ed ... View more