none
Filtering Rows in a Server-Client Sync Scenario RRS feed

  • Question

  • In my scenario, I want some tables to always sync, and some tables to only sync if the client flags that record to sync.

    I was told that I would need to create a different scope for each client. Do I just need to come up with a unique scope naming scheme to prevent multiple client from using the same scope? If so, can someone recommend a good way to name these scopes uniquely.

    Also, there will be a large number of tables of which each client will have exact, complete copies. Does that mean each client will have two scopes, a personal scope that contains the tables and rows they are working on, and a second "global" scope that every client will use?

    Also, the client has a few options to sync their data: Upload and Remove Local Copy, Upload but Keep Local Copy, Refresh Local Copy, Remove Local Copy

    For the situations when the client chooses to drop the local copy, deprovisioning those records makes a lot of sense. But when the client is going to keep or refresh the local copy, I'm not sure about the appropriate way to handle the provisioning. For one, when I deprovision the client, will I be able to perserve some of the provisioning. I know I can deprovision a scope on my Sql provider, but I didn't see on for my SqlCe provider. Or, in this scenario would I need to leverage the Metadata Storage Services to perserve the local change tracking when a the client scope is de/reprovisioned?

    I know that I would supply a filtering expression to download/upload the flagged rows. However, I am still not sure about the related tables. What is the best way to sync several rows and all of the rows in the related tables? Do I have a different SqlSyncAdapterBuilder for each flagged row and each of the related tables rows?

     

    Please help!

    Monday, November 29, 2010 8:40 PM

All replies

  • I've been reading http://msdn.microsoft.com/en-us/library/bb902819(v=SQL.110).aspx, and I think I understand a little bit more...

    I believe I won't be needing the peer-to-peer capabilities of Sync Framework. I will be using a server-client or hub-spoke model. Because of this, I won't need using the SyncOrchestrator. I will use the SyncAgent instead. Now, I think I don't need to declare a scope as I would using the SqlSyncProvider and SyncOrchestrator.

    Since the user decides when to download and when to upload, I don't think I need the change tracking. I just need a timestamp.

    I'm starting to think Sync Framework is not the right solution for this application.

     

    Any thoughts?

    Tuesday, November 30, 2010 4:20 PM