We have just upgraded a customer today to 10.5.1 from 10.4.1 and we have found that syncing with Collector now fails. The edits get pushed up to the enterprise geodatabase but do not come down from ArcGIS Server from the enterprise geodatabase.
After investigating it appears that during the sync process the GP tool is looking for the wrong schema in SQL Server for some of the temporary tables that get created.
If we go offline with Collector the replica creation works fine, and if we sync, the edits get pushed up from Collector but it does not refresh the data from the enterprise geodatabase to the mobile device – we get a 500 sync failed error.
NOTE: The feature class is GIS.GISADMIN.SomePoints – syncing fails – ArcGIS Server has correct editing permissions assigned
If we give the ArcGIS Server creation rights on the enterprise geodatabase and create the feature class to be GIS.” Domain\server_ArcGIS”.SomePoints then all works as expected. If we set ArcGIS Server to connect to the enterprise geodatabase as the data schema owner (as a db connection GISADMIN) all works as expected.
This workflow was fine 10.1 through 10.4.1 – this customer has been using it.
Please note that versioned feature classes work as expected. It is just an issue with archiving.
Also be aware we have applied the recent SQL Server Permissions patch (10.5.1)
Has anyone hit this? This seems like a bit of a biggie.
Solved! Go to Solution.
The issue is at 10.5.1 and 10.6 not at 10.5. Syncing works at 10.5. There is a 10.5 patch associated to sync at 10.5 Esri Support 10.5 (10.5.1) . This fixes a bug that occurs if you are using a workflow that includes copy and register of your replicas. Sync will fail without the patch is the user registering the replica did not create the replica or is an admin
I have observed the exact same issue, but did not think to test the scenario you found that works.
See: Download Sync not working in AGS 10.5.1 . In my case it is a Runtime application that presents the identical issue. I honestly question whether esri tests their software at all. This is the standard configuration, how can it never have been tested.
We also tried to upgrade to server 10.5.1 and found the same problems so we rolled back to 10.5. Does ESRI know this is a huge problem? I can't find any bug reported that mentions this. It is a show stopper for sure if you do any offline collector editing and suddenly the sync is not working.
I have been trying to work through this will Esri Inc support but at this point they haven't been able to reproduce - even though I have done it consistently in Azure and on various customer sites. Have you logged a support call and shraed your workflow with Esri?
Hi, AFAIK they didn't - the issue is in the sync tools - when it is looking for the onprem changes it is looking in the wrong schema for a temp table - in SQL anyway - which causes it to fail. I would most definitely log an issue and also highlight you had to roll back to ensure your workflow didn't break.
Full disclosure, I rarely if ever work with syncing, but throwing this out there in case it's helpful; getting SDEINTERCEPT logs may help identify if there's a invalid SQL statement that's being sent. If it's schema related, you should be able to identify this in the SDEINTERCEPT logs:
They may help Support log a bug if required.