Offline sync geodatabase: Implement server wins scenario?

[FridjofSchmidt]

In an offline workflow we have a requirement that if a row was updated both on the server and on the client side, the server's representation should prevail (server wins scenario). However, when I start a sync job with SyncDirection set to Bidirectional, the local changes will be uploaded first and overwrite the updates on the server row. On the other hand, when I set SyncDirection to Download (to get updated rows from the server first), the locally modified row will not be updated with the server's modified data. Instead, a SyncLayerResult is returned for the affected table with an error entry for the conflicting row:

Service error code 3070: Update failure. There are pending edits on the feature. This feature will not be synchronized.

This error seems to indicate a conflict (not a lock e.g. by a pending edit session). What would be the best approach to integrate the server's updates and overwrite any local updates in case of conflicts? I haven't found any conflict resolution settings in the Esri.ArcGISRuntime.Tasks.Offline namespace, such as a FavorClient/FavorServer switch. I thought about keeping the downloaded delta geodatabase, in case of errors retrieving the affected features from there and applying the updates to the local geodatabase one by one. But I was wondering if there is a more convenient way or better support for such scenarios in the SDK.

By the way, I am presently working with Runtime 100.15 but will soon upgrade to 200.x. Our data is not registered as versioned but with geodatabase archiving enabled.

[ViktorSafar]

I had the same problem (without getting any answers): https://community.esri.com/t5/net-maps-sdk-questions/applydeltaasync-giving-update-failure/m-p/15612...

First I ended up downloading a new replica after local delta upload. However, replica preparation from calling /createReplica takes forever. So I ended up creating a local backup of my local gdb after download. Then after sync up, I would download a server delta, replace my "working" gdb with the local backup, and apply the server delta to the local backup.

I am VERY MUCH open to other solutions.

[EricBader2]

Are you using a servicefeaturetable directly , or are you using a serviceGeodatabase first to get the service feature table ?  I’m wondering if you are using serviceGeodatdatabase, you can undo those local edits wherever there are conflicts. Do you think that would work?

[FridjofSchmidt]

Thanks Eric,

From what I saw in the API reference this is not exactly what I am looking for, because it seems to undo all of the local edits, whereas I only want to undo the conflicting edits.

At present, my approach is:

var gdb = await Geodatabase.OpenAsync(localPath);
var syncTask = await GeodatabaseSyncTask.CreateAsync(new Uri(serviceUrl));
var syncParams = await syncTask.CreateDefaultSyncGeodatabaseParametersAsync(gdb);
syncParams.KeepGeodatabaseDeltas = true;
syncParams.GeodatabaseSyncDirection = SyncDirection.Download;
var job = syncTask.SyncGeodatabase(syncParams, gdb);
job.Start();
var results = await job.GetResultAsync();

Next, if there are any results (indicating errors), I will iterate those with ErrorCode 3070 (apparently conflicts), figure out by table name and GlobalID where the conflicting delta features are stored in the delta geodatabase (job.GeodatabaseDeltaInfo.DownloadDeltaPath) and apply their values feature by feature as edits to the local geodatabase.

I am not happy with this workaround because it means that those edits will be uploaded to the server again as deltas on the next round trip, although the values correspond to what the server already has. I would prefer undoing the edits to the individual features so they won't appear as edits during the next upload. But I need to keep and upload the edits to all other features that have no conflicts.