CODEWITHSUNDEEP
.netmicrosoft-sync-framework
David
David

Reputation: 218960

Swapping Out Client-Side Sync Databases

We sort of shot ourselves in the foot at a client site with regards to the Microsoft Sync Framework when troubleshooting a particular production issue...

We have a central server as the data system of record which exposes a WCF service over which we use Sync Framework 2.0 to synchronize data with disconnected client instances. (Many of the details of the implementation are unknown, it's an inherited codebase.) When troubleshooting a problem on a user's machine at some point in the past, a decision was made to wipe out a particular client's local database and replace it with a known good copy from another client.

Everything seemed to work for a while. But there was a detail in the implementation that was unknown to us at the time. Sync internally tracks client database identity. What this meant was that the server couldn't distinguish between the two clients. So one would sync their data and then the other would be left in an unknown state.

We've identified affected users, we're identifying affected data, and we're brainstorming potential solutions. For that latter part, I'm wondering if anybody here has any experience with the Sync Framework and can suggest a potential course of action?

One potential approach we're considering is to identify where and how Sync internally tracks that identity (perhaps a GUID somewhere?) and to change it. This sounds like the quickest fix, though it would at least still leave us with a necessity to touch the affected records again to trigger them to synchronize again.

We don't want to risk losing data, so we're hesitant to drop the client databases and re-provision. But more to the point that process of provisioning a fresh database is a significant hit to resources and user downtime in the current setup, so it's something to avoid if possible.

Does anybody here have experience with the Sync Framework? Has anybody faced this problem before? What avenues of approach would you suggest?

Upvotes: 0

Views: 421

Answers (2)

Yahia
Yahia

Reputation: 70379

Your idea sounds ok, but to at least get a feeling of the risks involved you need to make sure that the inherited codebase doesn't contain any "surprises"... please provide more information:

  • Which "sync provider" is used ? DB/File/Custom ?
  • What are the implemented/configures "conflict resolution rules" ?
  • Which version of the framework ? 2.0 or 2.1 ?

EDIT - as per comments:

I am not 100% sure - please teast this first on one client and verify the results!
First replace the client GUID on the client which has accidentily gotten a copy of some other client (otherwise the "correctly working" gets messed up!).
Then call PerformPostRestoreFixup for this client db.
for some more details see
http://msdn.microsoft.com/en-us/library/ee617375.aspx
http://msdn.microsoft.com/en-us/library/bb726041.aspx

Upvotes: 1

JuneT
JuneT

Reputation: 7860

unfortunately, its not just a matter of replacing Guids on the scope tables.

If your clients are on SqlServer or SqlExpress, you can run PerformPostRestoreFixup and Sync Framework will adjust the client Id and the replica key map for you.

the next time you initialize a client using a backup from another client, make sure you run PerformPostRestoreFixup on the restored copy.

in your case where the clients are potentially out of synch already, you may have to do some verification after the PerformPostRestoreFixup

Upvotes: 0

Related Questions