locked
Sql Express provider clarification needed RRS feed

  • Question

  • Hi, I'm new to sync framework and currently investigating it to see if I can use it in a development that requires to sync data between a central office using sql server standard and remote offices using sql server express. The sync will be bidirectional.
    I'm very enthusiastic about this possibility and I think the SyncFx its just the way to go, but I have read a lot of articles and checked examples and I have some questions I need to clarify before moving forward.

    1) I have seen in the example for SQL Server - Sql Server express client synchronization that you need to program your own sql express client provider. Why is this? Why can't I just use the DbServerSyncProvider in both ends?

    2) In the same example, the client database holds two metadata tables named "anchor" and "guid" while the server database doesn't. I guess this is related to the first question but I can't see why. 

    The example I'm talking about is this:

    3) I have seen also the Peer to Peer architecture and I think it can also suit my needs in this scenario. Which are the main differences I have to take into account to select one or another? I'm thinking that bidirectional Client-Server sync is a special case of P2P in this case and that going from scratch with a P2P architecture gives me the flexibility to sync between clients in the future.

    Thanks in advance for your help!
    Wednesday, March 3, 2010 1:10 AM

Answers

  • Hi Manger,

    your first two questions refer to the offline scenario (hub-spoke). In the offline scenario, sync providers come in pairs of client and server. You cannot sync server to server nor client to client ( a scenario more appropriate for collaboration/peer to peer). So you can't use DbServerSyncProvider on both ends. (however, looking at the sample SQLExpress client provider, you'll see it's based on DBServerSync :) ). You need to write (or use the sample SQL Express provider) because SyncFx even in V2 doesnt come with a SQL Express client provider out-of-the box for the offline scenario.

    For your 2nd question, in Offline scenario, only the client keeps track of what has been uploaded and downloaded. The server never keeps track of what it received or what it sent. So the anchor table is only on the client side to keep track of the anchors for last sent and last received data.

    As for your last question, one of the good things I like about Peer to Peer scenario is the provisioning part. It automates creation of the database objects necessary for change tracking. Of course, you have the peer to peer, client to client ability to synch.

    cheers,

    junet
    • Proposed as answer by JuneT Friday, March 5, 2010 3:53 PM
    • Marked as answer by Manger Saturday, March 6, 2010 2:33 AM
    Wednesday, March 3, 2010 2:57 AM

All replies

  • Hi Manger,

    your first two questions refer to the offline scenario (hub-spoke). In the offline scenario, sync providers come in pairs of client and server. You cannot sync server to server nor client to client ( a scenario more appropriate for collaboration/peer to peer). So you can't use DbServerSyncProvider on both ends. (however, looking at the sample SQLExpress client provider, you'll see it's based on DBServerSync :) ). You need to write (or use the sample SQL Express provider) because SyncFx even in V2 doesnt come with a SQL Express client provider out-of-the box for the offline scenario.

    For your 2nd question, in Offline scenario, only the client keeps track of what has been uploaded and downloaded. The server never keeps track of what it received or what it sent. So the anchor table is only on the client side to keep track of the anchors for last sent and last received data.

    As for your last question, one of the good things I like about Peer to Peer scenario is the provisioning part. It automates creation of the database objects necessary for change tracking. Of course, you have the peer to peer, client to client ability to synch.

    cheers,

    junet
    • Proposed as answer by JuneT Friday, March 5, 2010 3:53 PM
    • Marked as answer by Manger Saturday, March 6, 2010 2:33 AM
    Wednesday, March 3, 2010 2:57 AM
  • Hi Junet,
    Thanks for the quick response. The hub-spoke scenario is more clear now.
    I will investigate the P2P scenario more in-depth before deciding which one to use.
    Regards,
    Manger

     


    Saturday, March 6, 2010 2:33 AM