Share via


Sync framework might fail to sync data

Database sync might not work if we copy the same database file to all the clients after provisioning it.

Recently I came across a very interesting Sync framework issue. The customer had two mobile clients connected to the server . He was making some changes on one of the Client and as expected it was getting pushed to the server. But the issue was that it was not propagated to the other clients.

However if some changes were made on the server directly, it was propagated to all the clients.

clip_image002

After doing further research I found that If we copy the client sdf Before it is provisioned and then provision them separately, it works. However If we copy the client sdf after provisioning then it fails.

What actually was happening is that When we provision a client it generates a unique ID for the client.

If we have 2 clients say A and B. And we copied them after provisioning then both of them will have same ID. But if we copy them before provisioning and provision them separately they will have a unique ID.

Let’s say we make a change on A and synced it with the sql server . We will see one upload. Now if we try to sync client B, we won't see any download because, Since the ID for both A and B are same the server thinks that I have just copied the data from this same client why do i need to sync it back to him again. That's why we need to copy the sdf before provisioning or create a new sdf.

 

Author : Snehadeep(MSFT), SQL Developer Engineer, Microsoft

Reviewed by : Ambuj(MSFT), SQL Developer Technical Lead, Microsoft

Comments

  • Anonymous
    June 16, 2011
    the other options you have are to use GenerateSnapshot on the 1st SDF to create copies of the SDF that you can distribute to other clients especially when you want to distribute SDF with data already otherwise the 2nd and subsequent clients' first sync will pull data down. another approach will be to create a backup and do a PerformPostRestoreFixup after restoring on another client.

  • Anonymous
    June 16, 2011
    The comment has been removed