none
Strange Upload behaviour in N Tier scenario RRS feed

  • Question

  • Hi JuneT,

    My app looks like this: Server: SQL-Server, clients using SQL Server CE. The sync is done with a WCF-sync service hosted in IIS. I am using Sync Framework 2.1 and created the sync service and proxy based on the MSDN sample I found: WebSharingAppDemo-CEProviderEndToEnd .

    My app has three scopes: 1) Download: data shared among all users, 2) Download: Filtered data for the specific user 3) Upload: new data (orders) created by the user (this scope is not filtered).

    1) and 2) work perfect

    While testing my application the upload shows some behaviour I do not understand.

    I started with provisioning client and server. I saved the empty client db as base template for my tests.

    I run my app in the context of user1 within Visual Studio and downloaded his data. Created some orders and synced again. The orders (and details) are uploaded. I created a backup of the client db.

    Then I deleted the client db and started over again with the empty client db, this time in the context of user2. Data is downloaded but the orders (and details) are not uploaded any more.

    Next I tried: I installed the app in a blank virtual machine. I run the app in the context of user3: download and upload works.

    Next: On my dev computer I then restored the client db (the one that was working in my first test). This time the upload does not work anymore. I hooked into the changesselected event: there are no changes detected. I also subscribed to the uploadchangesfailed event: this is never raised.

    Hope you can point me in the rigth direction to understand what is going on and how to fix it.

    Thanks
    Christian
    Monday, July 23, 2012 3:38 PM

Answers

  • Racing_Prog is on the right track. the issue has something to do with back up and restore.

    each replica in the sync community gets some sort of unique identifier (a replica id). when you copy databases, you have scopes having the same replica id.

    assuming you have Server A and Client A, you sync them and Server A records the sync knowledge of what it synched with Client A.

    you then copy Client A Db to Client X and sync it. Although the DB is in Client X now, it still has the id of Client A and presents it during sync. So when Server A asks what do i know about this other DB, it thinks it already synched with the Client X db since it has the id of Client A Db.

    unfortunately for SQL CE, there is no PerformPostRestoreFixup equivalent.

    If you want to distribute a pre-provisioned database (it can even contain data), use the GenerateSnapshot method. this creates an SDF copy which Sync Fx can detect as a snapshot and when it does, it will adjust the sync metadata accordingly (it gets a new id) on first sync.

    • Marked as answer by chl-h Monday, July 30, 2012 3:45 PM
    Tuesday, July 24, 2012 1:23 AM
    Moderator

All replies

  • sounds like "post-restore fixup" is something you should look into....
    Monday, July 23, 2012 4:37 PM
  • Racing_Prog is on the right track. the issue has something to do with back up and restore.

    each replica in the sync community gets some sort of unique identifier (a replica id). when you copy databases, you have scopes having the same replica id.

    assuming you have Server A and Client A, you sync them and Server A records the sync knowledge of what it synched with Client A.

    you then copy Client A Db to Client X and sync it. Although the DB is in Client X now, it still has the id of Client A and presents it during sync. So when Server A asks what do i know about this other DB, it thinks it already synched with the Client X db since it has the id of Client A Db.

    unfortunately for SQL CE, there is no PerformPostRestoreFixup equivalent.

    If you want to distribute a pre-provisioned database (it can even contain data), use the GenerateSnapshot method. this creates an SDF copy which Sync Fx can detect as a snapshot and when it does, it will adjust the sync metadata accordingly (it gets a new id) on first sync.

    • Marked as answer by chl-h Monday, July 30, 2012 3:45 PM
    Tuesday, July 24, 2012 1:23 AM
    Moderator
  • If you want to distribute a pre-provisioned database (it can even contain data), use the GenerateSnapshot method. this creates an SDF copy which Sync Fx can detect as a snapshot and when it does, it will adjust the sync metadata accordingly (it gets a new id) on first sync.

    I will modify my code (hopefully today) and work with "GenerateSnapshot" created SDF - DB and keep you updated with the result.

    Actually I could not use the "postrestorefixup" with the server database, because this always produces a timeout, probably because some tables have around 1 million records, therefore I normally  do remove the complete store and provision the database. I was in the impression that this has the same effect as a "postrestorefixup".

    Tuesday, July 24, 2012 9:55 AM
  • the SqlSyncStoreRestore class  where you call PerformPostRestoreFixup has a CommandTimeout property that you can set.
    Tuesday, July 24, 2012 10:45 AM
    Moderator
  • Hi JuneT,

    After setting the CommandTimeout from PerformPostRestoreFixup, I was able to run this. Thanks for hint, before I tried to increase the timeout of the connection string....

    Next I used the "GenerateSnapshot" created SDF-db. My first tests look very promising (no problems so far, but I will do some more testing).

    Another question:

    the server db gets its data from an import of files from another system. One table holds the user information (especially the number for the filtered scope). If a new salesperson enters the company, I want to automatically provision the server and client with the filtered scopes. To accomplish this I did this:

    For every record in the salesperson table I check weather the filtered scope exists, if not I add the scope to the client and server dbs.

    At the end I generate a snapshot and copy this file to a website.

    From within my windows app it is possible to download the generated client db.

    Is this the right approach?

    all seems to work fine, but I am a bit afraid, that newly added scopes might break the ability to upload data for clients using a former version of the client db.  

    Thanks
    Christian



     
    Wednesday, July 25, 2012 2:58 PM
  • sounds good to me.
    Thursday, July 26, 2012 3:51 AM
    Moderator
  • HI JuneT,

    very good, looks like everything is now working as expected.

    Thanks very much

    Christian

    Monday, July 30, 2012 3:45 PM