Httpsync with scopes and change tracking

[needledrag]

I have a few questions on this, I'd greatly appreciate any knowledge on the subject.

a)
I've got 2 scopes setup (setupPush, setupPull) from a Xamarin client (sqlite). I'm syncing to an asp.net rest api and the server db is Sql Server with change tracking on. As I have two scopes setup on the client (potentially called at different times), do I have to set up two SyncServers in the asp.net startup.cs file? ie

 services.AddSyncServer<SqlSyncChangeTrackingProvider>(connString, "pullTables", setupPull);
 services.AddSyncServer<SqlSyncChangeTrackingProvider>(connString, "pushTables", setupPush);

Where "pullTables" and "pushTables" are the scope names setup on the client too.

b)
I've made changes to my table schema (renamed some columns etc..)
On the Xamarin client I can reset my emulator to clear the database completely (testing from scratch).
On the Sql Server I have removed change tracking from the tables and set change tracking to off and then back on. I've also dropped the 'scopes' tables that were created by DMS and all the relevant stored procs.

However I get an error when attempting to sync which is 'invalid column name Fullname' which is a column that's been renamed.
Is this because Sql Server Change tracking still has logs that refer to the original schema (previously column was called Name)? If so is it possible to completely remove all knowledge of the previous change tracking? I used CHANGETABLE to query if any changes were in the table but since I disabled Change Tracking on it, it seems to be cleared so I'm not sure why I have an error on the changed field name?

Thanks in advance for any suggestions.

Regards
Shaun

*Update:
I reverted back to using a single scope in case I and set up the scopes incorrectly but the problem persists. I had it all working up until I made changes to the tables Column names. I realise on a prod environment you'd have to do some provisioning but as I'm still in development and table structure may change I was hoping to be able to clear it all down on client and server and start with a new dB schema. The only thing I can think of is that somehow enabling change tracking has kept a memory of the prior schema?

[Mimetis]

Multi scopes

Indeed, you can work with multi scopes. Be careful to have different prefix or suffix if your two scopes have differents tables / columns (otherwise u risk to override some stored proc from one scope with the other one)
If the scopes are exactly the same but one is for download only and the other for upload only you should be fine, I guess.
Your server side seems fine to me.

Deprovision

On the Sql Server, you should remove

• Stored Proc
• Triggers
• Tracking tables (not in Change Tracking Mode)
• Table Value Parameter type

I guess you forgot to remove the tvp

By the way, on the server side, you can create a quick console applicaition, declare a RemoteOrchestrator with the correct Setup and call the DeprovisionAsync() method

[needledrag]

The udt types were exactly it, all working now, much thanks.

[VagueGit]

I just hit a Gotcha experimenting with multiple scopes ... it seems if Scope1 is a subset of Scope2, Scope2 is not updated when Scope1 is updated. In detail:

Scope1 includes a single table, Table1.
DefaultScope is Table1, Table2 ... etc

A new database is created on the server and all tables have some initialisation data.
Sync to the client using Scope1
Update Table1 on the client
Sync using DefaultScope
Table1 changes are overwritten by server data, even through the client data is newer.

Now that I know this happens we can deal with it. It makes scopes less useful for us as there are times we only want to sync 1 table, as it is quicker and times when we want to sync them all because we don't know what changes have happened elsewhere. It seems that to use multiple scopes we would need to ensure no table occurs in multiple scopes and ensure each scope is updated in case there are remote changes.

For us it might be safer, though less performant, to stay with DefaultScope. I am testing with DMS 0.8.1-beta-0687. I don't know if this issue exists in other versions.