Is Sync the right choice for the following scenario? RRS feed

  • Question

  • Hi,

    I am new to the Sync framework and I have a case where we have 50 databases with the same schema. Some tables need to have the same data in all databases (and they are not necessarily reference data, in some cases they might need to be modified in any of the 50 databases), other ones have different.

    Connectivity between locations is not optimal: in some cases we might even have a dial-up connection. We need to be able to keep some tables in sync. We also need to be able to deploy schema changes en masse (I suppose we can use VS DB projects for the latter). Do you think that the Sync framework is the optimal choice, or some kind of selective merge replication should be preferable?

    If I start a synchronization task, and the connection is dropped before it finishes, when it will be restarted, will it continue from where it was, or will it start from scratch? Can I control which elements should have a  transactional logic?

    Let's test clickonce: http://recursive-cacophony.net/tec-goblin/Informatics.aspx
    Tuesday, September 27, 2011 12:24 PM


  • sync framework dont do schema syncs, so be prepare to roll your own solution to sync your schemas and update the sync metadata to reflect the new schemas.

    changes in a sync session are in a transaction and there is no partial sync. if you're in the middle of applying 50 of 100 changes and a fatal error occurs, dont expect the first 50 to be committed.

    if you enable batching, sync framework may resume from where it stopped uploading the batch files when a sync is interrupted. but all changes in the batch files would still be applied as a transaction. (e.g, you enabled batching and let's say the serialization of the changes is broken into 10 batch files, if connection breaks in file 5, sync fx may be able to detect that and resume uploading batch file 6 and above. but all 10 files will be applied in a single transaction)

    • Marked as answer by tec-goblin Wednesday, September 28, 2011 2:46 AM
    Wednesday, September 28, 2011 2:17 AM