Sync fails at 10.5.1 with 500 error

6209
27
Jump to solution
09-03-2017 08:05 PM
FraserHand1
New Contributor III

Hi,

 

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.

 

  • We have SDE schema with geodatabase repository
  • We have GISADMIN schema with feature classes
  • ArcGIS Server runs as Domain\server_ArcGIS (OSA authentication)
  • Feature classes have archiving enabled

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.

 

Many thanks,

Fraser

27 Replies
JoeHershman
MVP Regular Contributor

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

Thanks,
-Joe
FraserHand1
New Contributor III

Hi,

I passed it to out support team and they logged an issue with Redlands on behalf od the customer. From then I've been out of the loop but I don't believe it was resolved.

Thanks,

Fraser

0 Kudos
FraserHand1
New Contributor III

*our not out

0 Kudos
JustinBurdette
New Contributor III

Typo on my end, I meant 10.5.1.....we are at 10.5 now and sync works fine.

0 Kudos
LucasScharenbroich
Occasional Contributor

Rather than creating another post, I'll bump this one up.  On a fresh 10.5.1 installation I have run into the exact same issue that was very well-described in the post.

  • Feature class owned by a 'GIS' schema named TestPoints
  • ArcGIS Server connecting using OSA
  • Feature class has Archiving enabled
  • Push & Pull sync fails due to the SyncTools trying to access a "<domain\username>".TestPoints instead of GIS.TestPoints

I did try one variation where I created a separate DBMS user named "AGS" and used that in a DBMS connection string rather than an OSA connection string from ArcGIS Server.  The same error happened with SyncTools trying to query the AGS.TestPoints feature class.

There is a passing reference in the documentation about using synchronous vs asynchronous methods for checkout that states only asynchronous methods go through SyncTools.  

Prepare data for offline use—Documentation | ArcGIS Enterprise 

Is there any way to force Collector to use synchronous methods directly against the Feature Service endpoint instead of going through SyncTools?  That may be a way to work around the problem. 

In the interim, one can turn on "Push Only" synchronization in the Collector settings in order to avoid seeing the error in the application.  The downside is that the user needs to create a new checkout in order to see any new point that others have uploaded.

0 Kudos
JoeHershman
MVP Regular Contributor

The downside is that the user needs to create a new checkout in order to see any new point that others have uploaded.

This is a non-starter in our case.  The replicas are far too large and users only have access over a mobile network most of the time.  Both generation time and transport time individually  preclude this as something we could consider,  Certainly, hope this is resolved at upcoming 10.6 and Runtime 100.2 release because we would like to incorporate other fixes and new features from those upcoming releases

Thanks,
-Joe
0 Kudos
jaykapalczynski
Frequent Contributor

How do I roll back to 10.5 from 10.5.1?

What will this screw up?

Has ESRI stopped testing?  Seems like a critical error to simply not alert users before they go through the headache of upgrading, only to find out they have to roll back.  Either they knew about it or simply decided not to test their software.  Either way a little upsetting.

ScottPrindle
Esri Regular Contributor

The root cause of this issue is touched on in a few comments. Joe Hershmanshared the relevant patch for the original issue outlined by OP.

The issue is tied to the database connection file's credentials that were used when publishing the service. More specifically, if the data owner (ex. GISADMIN) differs from the service's publishing credentials (ex. Publisher, GIS, etc.), at 10.5 the sync would fail.

If this is the issue you're encountering, then the patch should be applied to your environment, or upgrade to the most recent release (if possible). If these options don't work, you can attempt to republish your feature services using the data owner (ex. GISADMIN). This is a workaround, so it should only be done if there are no concerns with this approach.

The bug (BUG-000103326) can be viewed here.

Thanks,

Scott

0 Kudos
jaykapalczynski
Frequent Contributor

I am running 10.5.1

  • I go to my Server that ArcGIS Server is installed on.
  • Double Click the .msp file
  • I get this error???

Esri Support 10.5 (10.5.1) 

Thoughts?  I am assuming that this patch will fix the 10.5.1 install and not the 10.6x

0 Kudos
JoeHershman
MVP Regular Contributor

It is a 10.5 patch, it will not work on any other version

Thanks,
-Joe
0 Kudos