Closed mrtncls closed 3 years ago
Regarding at your exception, seems it's occuring during a conflict resolution:
Dotmim.Sync.SyncException: Invalid object name 'TABLE2_tracking'.
---> Microsoft.Data.SqlClient.SqlException (0x80131904): Invalid object name 'TABLE2_tracking'
at Dotmim.Sync.BaseOrchestrator.InternalUpdateMetadatasAsync()
at Dotmim.Sync.BaseOrchestrator.HandleConflictAsync()
at Dotmim.Sync.BaseOrchestrator.InternalApplyChangesBatchAsync()
The problem is that .. you don't have any tracking table since you are using change tracking.... Do you have any way to reproduce the error ?
I think I found the issue Seems it's happening when
SqlSyncChangeTrackingProvider
providerConflictResolutionPolicy.ClientWins
Can you confirm this setup ?
The bug will be resolved in the next release.
As you did not upgraded yet, one solution you can use to prevent this bug is to intercept the conflict, assuming you are in the situation described in the last comment (SqlSyncChangeTrackingProvider
on client and resolution set to ConflictResolutionPolicy.ClientWins
)
This code is to put on the server side, using the RemoteOrchestrator
:
agent.RemoteOrchestrator.OnApplyChangesFailed(args =>
{
if (args.Conflict.Type == ConflictType.RemoteIsDeletedLocalIsDeleted
&& args.Resolution == ConflictResolution.ClientWins)
{
args.Resolution = ConflictResolution.ServerWins;
}
});
That way, you should not have the issue anymore
Let me know
In our application, we use the SyncAgent which is initialized like:
public SyncAgent CreateSyncAgent()
{
var source = CreateSourceProvider(
databasesConfig.DataSync.RemoteDbProvider,
databasesConfig.DataSync.RemoteDbConnectionString);
var target = CreateTargetProvider(
databasesConfig.RulesDbProvider,
databasesConfig.RulesDbConnectionString);
return new SyncAgent(target, source, new SyncOptions(), GetSetup());
}
private SyncSetup GetSetup()
{
var dbStructure = dbStructureClient.GetTableAndColumnNames();
var syncSetup = new SyncSetup(dbStructure.Select(x => x.Key));
foreach (var table in syncSetup.Tables)
{
table.SyncDirection = SyncDirection.DownloadOnly;
table.Columns.AddRange(dbStructure[table.TableName]);
}
return syncSetup;
}
Is the conflict resolution ClientWins by default? Otherwise it should be ServerWins as we don't set it.
SyncDirection is DownloadOnly for all tables. Is it possible to have conflicts with DownloadOnly?
Our application is not writing to this DB. Is connects but has a readonly dbcontext.
The RemoteOrchestrator is only used for deprovisioning when we need to re-init the edge db (after schema changes).
private async Task DeprovisionRemoteDatabase()
{
var serverScope = await remoteOchestrator.GetServerScopeAsync();
await remoteOchestrator.DeprovisionAsync(SyncProvision.StoredProcedures | SyncProvision.Triggers | SyncProvision.TrackingTable);
serverScope.Setup = null;
serverScope.Schema = null;
await remoteOchestrator.SaveServerScopeAsync(serverScope);
}
Does the failure happens on the server database or the client database ? (regarding the trace u get )
Hello, I am a colleague of Maarten's. We get the error on the client database.
Ok, it should work with this code
agent.LocalOrchestrator.OnApplyChangesFailed(args =>
{
if (args.Conflict.Type == ConflictType.RemoteIsDeletedLocalIsDeleted
&& args.Resolution == ConflictResolution.ClientWins)
{
args.Resolution = ConflictResolution.ServerWins;
}
})
I know it's not making sense when we read the code, but usually we are not resolving conflict on client side Anyway let me know if it's resolving your issue, until I release a new version
Ok, thanks for the code. We'll integrate it and monitor it for a few weeks and report back.
Hi
Is this issue solved now and released?
The issue is resolved and in the master branch, but not yet released You can grab the master branch and use it, if you are facing this issue
Next release is planned for July or August
Great, Thanks
We sync from a cloud db towards an edge db in one way both are using the SqlServerChangeTracking provider. We're using nuget 0.6.1 Both db's have changetracking enabled:
We're not able to reproduce but it happened 3 times on different systems. The sync was stable for weeks before it happened. It started when we added some records in the cloud db.
We want to understand what is causing this and how we can prevent this. Could this be related to the changetracking retention?
Investigations:
If we restart our application, the same exception will occur.
We can recover from it by removing the edge database and deprovision the sync (StoredProc, Triggers and TrackingTables).
Stacktrace from the sync command:
Sql profiler trace on edge database: