Select to view content in your preferred language

ArcGIS Enterprise 10.6.1 Sync Service: No path for delta data changes

3097
7
11-08-2018 08:29 AM
TobiasFimpel1
Frequent Contributor

Upgraded ArcGIS Server from 10.3 to 10.6.1, now getting below errors when attempting sync from Collector app.

Data is versioned; DB is Oracle; GDB tested v10.3 and v10.6.1; ArcGIS Server service is registered with credentials stored in item; service is configured to create a version for each User;

Have tried some general troubleshooting. Any ideas how to diagnose instead of the trial-and-error approach testing the countless variables that are in play in this setup?

Thanks! 

Tags (1)
0 Kudos
7 Replies
StevenRamirez
Esri Contributor

Hi Tobias, Thank you for posting this question to GeoNet. If in a previous version of ArcGIS Server 10.3.1, this was successful. Then the only item that has since changed being the upgrade, we would need to know what version the underlying Oracle DBMS is. It's possible the underlying DBMS may not be directly supported by ArcGIS Server at 10.6.X. For additional information please the system requirements page: Oracle database requirements for ArcGIS 10.6.x—System Requirements | ArcGIS Desktop. If you find that the DBMS is still supported then it would probably be best handled with a support case. 

Santa_Clara_CountyParks_and_Re
Emerging Contributor

Hi Tobias, 

Where you able to resolve this issue?  If so, do you recall what the issue was?

Thanks,

Seth 

0 Kudos
EricJackson1
Regular Contributor

We are experiencing the same issue Portal 10.6.1.  Did you find a solution?

Eric

0 Kudos
SethHiatt
Emerging Contributor

Eric,

In our case the issue was that we were publishing with a database account that had edit privileges but no create privileges.   We gave the following access to the account; create table, create view, create procedure, and create function. Everything works fine now, although I would prefer that we could continue to publish with fewer privileges.  Evidently this is due to a bug. Hopefully Esri will resolve it in the near future.

Seth

LeonS
by
Frequent Contributor

This issue was affecting a collaboration I had set up between Portal and AGOL.  Adding these additional privileges to my DBMS user fixed the issue.  Thanks for sharing!

0 Kudos
TJSimons
Esri Contributor

Hey Tobias,

 

Seth Hiatt is correct,  the cause of the issue is related to the publishing database account not having the CREATE TABLE privilege.

 

The database user needs to have CREATE TABLE in order to create the SDE_UUID_TEMP$ table.  This table is required for replication in an Oracle geodatabase.  It is used to discover the lineage of a given object via its GlobalID value.  This is why you receive the error "No path for delta changes."

 

The table is created in the users' schema when synchronization is performed.  After the sync, the rows are deleted, but the table remains.  So you can revoke the CREATE TABLE privilege from the database user after running through the sync workflow one time. You don't have to do this for each service you publish, just once for the publishing user. 

This issue does not occur when publishing as the data owner, because the data owner typically has CREATE TABLE. 

 

http://desktop.arcgis.com/en/arcmap/10.6/manage-data/gdbs-in-oracle/replica-storage-oracle.htm

"When a geodatabase is synchronized with its relative geodatabase, a table is created in the user's schema of the replica geodatabase (the one that is sending the changes to the relative geodatabase) to track the lineages of altered datasets.

 

The SDE_UUID_TEMP$ table is used to discover the lineage of a given object via its GlobalID value.

 

The SDE_UUID_TEMP$ table is not removed when the session exits because the table will likely be reused in another session."

 

To resolve this issue, grant CREATE TABLE to the publishing database user.  If you would like for that user to not have CREATE TABLE, revoke it after running the sync workflow successfully.

0 Kudos
pfoppe
by MVP
MVP

I realize this thread is related to Oracle databases, but we had a similar error message with a back-end SQL Server environment.  

Cross posting for good measure... here was our fix on SQL Server - https://community.esri.com/thread/248923-collector-offline-map-sync-failed-unknown-error-occurred#co... 

0 Kudos