SqlSyncChangeTrackingProvider with single server and many clients

[slawomirpiotrowski]

Hello,

I'm using SqlSyncChangeTrackingProvider with many clients synchronising with a single server.

It is possible to add new clients during lifetime of the application.

If incremental synchronisation fails for whatever reason, including change of metadata of synchronised data (like adding new column or something) than I'm doing Deprovision + drop destination tables from destination (client) database + Reprovision + full synchronisation.

What is the problem? DotMim.Sync during Deprovision executes ALTER TABLE ... DISABLE CHANGE_TRAKCING, and this operation damages synchronisation with other clients.

So if metadata change for any of synchronised clients, than I need to execute operation that break synchronisations with other clients.

Can I skip this operation by configuration somehow? I have tried to pass some parameter to DeprovisionAsync (SyncProvision) to let it know that it shouldn't delete change tracking informations, but failed.

[slawomirpiotrowski]

I was able to work around that problem by creating custom class based on SqlChangeTrackingTableBuilder and overriding Task GetDropTrackingTableCommandAsync(DbConnection connection, DbTransaction transaction) to return a no-op SQL. This way DotMim.Sync doesn't disable change tracking during deprovision.

But DotMim.Sync already has information about clients that are synced to given table, so I think during deprovision it should only disable change tracking for a table if it's not synchronized with any other client.

To recreate the problem:

1. Create any database to be sync'd (server), put some data there.
2. Create synchronization to client1, allow it to synchronize.
3. Create synchronization to client2, allow it to synchronize.
4. Do some updates to original table.
5. Synchronize client1.
6. Deprovision client1.
7. Try to synchronize client2, it will fail as change tracking on tables synchronized with client1 was disabled in step 6 even if client2 wanted to track them too.

I have had this problem using SQL change tracking, but I think it would fail in similar way when using triggers and custom tables.