locked
Workaround to implement ClientSyncProvider for PCs (Sql Server as client db) RRS feed

  • Question

  • Hi all,

    I am checking feasibility of using microsoft synchronization services for one of our recently development work.

    The scenario is we have one server machine and many clients ( clients can be either PCs or Windows mobile devices). We need to synchronize data among server and clients. Synchronization between server and windows mobile devices is working properly.

    I have noticed that there's not default ClientSyncProvider implemetation for PCs. As a workaround, I have implemented a ClientSyncProvider instance with keeping DbServerSyncProvider instance as a composite. I am managing the anchor handling by myself. Now the synchronization is working properly.

    public class DemoClientSyncProvider : ClientSyncProvider
    {
    private DbServerSyncProvider dbServerSyncProvider;

    //
    //  ClientSyncProvider method implementation goes here
    //
    }

    My doubt is, whether this is an appropriate way to handle Sever to PC synchronization? Will there be any shortcomings in this approach?

    Your comments are really appreciated.

    Pushpaka Rambukkanage


    • Moved by Max Wang_1983 Friday, April 22, 2011 7:22 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Sunday, June 15, 2008 10:37 AM

Answers

  • Hi Pushpaka

    From the knowledge I collected in the last weeks of Sync Framework, your approach to use DbServerSyncProvider on the client side seems pragmatic, as the important change detection and metatables for change detection (Tombstone, ...) can be handled the same way on client and server.

    Did you think about the follwoing options for your Project:
    - Use SqlServer Compact also on PC Clients: -> Advantage of using the same client database for all clients
    - Use SqlServer 2008 as Server (And PC Client Database): -> Advantage of not having to define triggers, procedures and metatables for change detection, as will be supported in the core of sqlserver 2008

    Regards
    Oliver
    Sunday, June 15, 2008 3:33 PM

All replies

  • Hi Pushpaka

    From the knowledge I collected in the last weeks of Sync Framework, your approach to use DbServerSyncProvider on the client side seems pragmatic, as the important change detection and metatables for change detection (Tombstone, ...) can be handled the same way on client and server.

    Did you think about the follwoing options for your Project:
    - Use SqlServer Compact also on PC Clients: -> Advantage of using the same client database for all clients
    - Use SqlServer 2008 as Server (And PC Client Database): -> Advantage of not having to define triggers, procedures and metatables for change detection, as will be supported in the core of sqlserver 2008

    Regards
    Oliver
    Sunday, June 15, 2008 3:33 PM
  • Hi Oliver,

     

    Thank you for spending time on my concern and help me.

     

    We have two types of synchronization

    1. Server with mobile devices - light sync- e.g. sales rep entering transactional data

    ADO.NET sync services is finalized to use in this situation.

    2. Server with laptops - full sync - e.g. an operator ( operators can belong to a partner company) changing both master (partially) data and transactional data (completely).

    For the sceond scenario also, we see feasiblity of using ADO.NET sync framework now.

    -These clients contain considerable amount of data so we can't use sqlce database, but have to use at least Sql Express database.

    -Yes, your suggestion is correct, we will work on to see, how to use Sql Server 2008 for our application (because we have to port currently developing application to Sql Serve r2008).

     

    For the first scenario, server to mobile sync, it is recommended to use a staging database for the intermediate data transfer. Can anyone help me one this subject? how we can define such a database and what are the concerns designing such a database?

     

    Regards,

    Pushpaka

     

     

     

     

     

     

    Monday, June 16, 2008 8:33 AM