Sync Framework RRS feed

  • Question

  • Hi,

    We need to refresh the client dashboard(windows application) for every 15 seconds with server data.

    Server gets data every 15 seconds(may be 1000 records).

    This inserted data need to update in each client.

    So, we have decided to sychronize the server data to the clients with sync framework.

    Our Server is sql server 2008 and Winodws 7

    Client has SQL CE and .Net framework 3.5

    Client has timer which raises event every 15 seconds to synchronize the data with sync framework(WCF) and refresh the data with entity framework in the client.

    But I read in the articles sync framework is for offline data.

    Did you find any issue in the above design?

    Could you please suggest to go in the rightway?

    I really appreciate your help



    Saturday, December 4, 2010 9:22 AM

All replies

  • Hi, Latha.

    Microsoft Sync Framework is not only for offline. It offers you the possibility to make some changes offline and then upload them to the server. Being offline is not a requirement.

    Is the client in your scenario going to make changes to the data, or it will only "consume" data by viewing it ?

    Monday, December 6, 2010 9:47 PM
  • Thanks for quick response. Client is only consumes the server data. But We need to refresh server data for every 15 seconds in the clients. Clients count may be 50.
    Tuesday, December 7, 2010 4:21 AM
  • This sounds like a simple, straight forward scenario. You will need to provision your database in order to track changes on the server side. Then in the event start the sync session with direction downloadOnly, since client does not update the data...


    Let us know if you have more questions. You can refer to the samples as a starting point for coding.

    One more question though. Does server update existing data, or insert new items always ??

    • Proposed as answer by Ganeshan Thursday, December 9, 2010 5:45 PM
    Tuesday, December 7, 2010 4:41 AM
  • There may be updates(frequent) or inserts(rare) in the server. We did a sample to sync through WCF service using sync framework. But my doubt is 'can we face any performance issues in the future while synching all the clients at a time frequently'

    Tuesday, December 7, 2010 6:30 AM
  • you can think of Sync Fx as just like any other database application. so you can apply the same optimization techniques with database and WCF (e.g., indexing, filtering to reduce the result set, wcf instancing, etc...)

    in your case, i would watch out for the number of rows and size of the change dataset plus the fact that you want each client to sync every 15 seconds.

    • Proposed as answer by Ganeshan Thursday, December 9, 2010 5:45 PM
    Tuesday, December 7, 2010 3:52 PM
  • Thanks for the clarification. We will implement optimization techniques in database and WCF. As per your conversation I dont think we would get the problem in future by using this.
    Wednesday, December 8, 2010 4:30 AM
  • Hi Adrian,
    In the example presented at the start of this thread, does the scenario where the server database is 'hidden' behind a firewall and the client application is distributed across the world wide web pointing at a single 'exposed' web service, have any impact on the use of Sync Fx ?
    Thursday, December 9, 2010 10:31 AM
  • I don't think there should be any issues.

    SyncFX talks to the service, which retrieves the data from DB, so you should be OK.

    Thursday, December 9, 2010 5:56 PM
  • Hi Adrian,

    Thanks for the reply.

    Is the implementation of SyncFX for the rapid refresh of data in a smart client application, from a central server, something you have seen often done.

    In my experience this type of interaction would be handled by the central server putting changes (the delta) in a queue. Then getting the clients to polls on that queue using a long polling mechanism, waiting for changes, which then allows for real time notifications of changes. On the client side, the data is kept in memory (DataSet) and the presentation is binded to the data, the binding is aware of data changes and repainting is done on change.

    The use of a database on the client side seems an overkill for this type of solution and to me would seem to add an extra layer of complexity to the solution and an extra overhead in terms or resource usage on the client side (CPU / Memory)

    I can understand the advantage of SyncFX and the client side database when the client is making changes to the data and you want to retain the advantages of database (ACID), but for a read-only client application it does seem a step too far.

    I would be interested in your thoughts on this.


    Wednesday, December 15, 2010 1:04 PM
  • The key step in your scenario seems to be detection of the DELTA (to avoid downloading all items each time). This step is performed automatically by the Sync Framework in the Change Detection step.

    However, it seems that you can achieve the desired result even without Sync Framework, because your client is just "consuming" the data, without making any changes to the data, so you are not going to have any conflicts, constraints etc.

    The approach you mention seems good to me, as long as the way the server detects the DELTA is not a performance bottleneck.

    Just one clarification - what exactly do you put in the queue? The item's data at the moment the item was changed? And if same item is updated say 5 times in a row, do you keep track of which change was the last?

    One thing you can do in this algorithm is instead of adding the actual item's DATA, add item's Metadata (such as item Id and table or something like this).

    Then, when client pulls the changes, get the latest actual data for that item straight from the database. This way, if an item was updated say 10 times, you will pick the latest data.


    Hope this helps.


    Wednesday, December 15, 2010 8:11 PM