locked
Sync Services for ADO.NET (Devices) P2P? RRS feed

  • Question

  • Hi folks,

    The information regarding Sync Services for ADO.NET for Devices has been pretty limited after CTP1.
    Are there any plans to include peer to peer support in time for RTM?

    I'm working on an app with a device component and desktop component. Both use SQL Server Compact 3.5 databases and I would like to sync them. I have actually already achieved this using a couple of hacks, but still have some issues. The client-server architecture isn't really suited for my app, because the user can opt to install only the device component, or both the device and desktop components. Peer to peer logically seems like the correct architecture to me.

    I know that this can be achieved by copying .sdf files from device to pc and then back, but as the .sdf files get larger, this option seems less feasible to me. I wouldn't want to copy 100MB files to sync just two records, for example (not that the databases will be that large, but my point remains).

    A goal of mine is to allow the user to only install the device portion, populate the database, and then later should he decide to install the desktop portion, all data could be synced to the desktop. Then, if the user loses his device, he has the data backed up on the desktop and can sync back everything to a new device.
    • Moved by Max Wang_1983 Friday, April 22, 2011 6:51 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Wednesday, July 23, 2008 3:18 AM

Answers

  • We do have plans about enabling P2P scenarios for the devices in the future. I do not have hard timelines on this yet for now.

    I know you mention devices, but are you looking at synching the compact databases that are on desktops or devices. Does one take a priority over the other?

    Wednesday, July 23, 2008 5:35 AM

All replies

  • We do have plans about enabling P2P scenarios for the devices in the future. I do not have hard timelines on this yet for now.

    I know you mention devices, but are you looking at synching the compact databases that are on desktops or devices. Does one take a priority over the other?

    Wednesday, July 23, 2008 5:35 AM
  • The app that I'm working on logs a lot of data on the user's device. This data can only be obtained on the device, because a GSM / UMTS radio is required. The user can perform some analysis and manipulation of the logged data on his device, but to be able to do full scale analysis and manipulation, he/she requires the desktop portion. Once the data has been manipulated on the desktop, it should then be synced back to the device. The new manipulated data can then be used on the device for other useful purposes. If one of the databases (desktop or device) gets deleted, the user should have the option of restoring the deleted database by pulling the data from the database which was not deleted.

    If I understood your question correctly, the priorities for my app are the following (both are important):
    • Peer to peer sync from device (SQLCE3.5) to desktop (SQLCE3.5)
    • Peer to peer sync from desktop (SQLCE3.5) to device (SQLCE3.5)

    I can think of some really cool ideas where the following scenarios would be useful:
    • Peer to peer sync from device to device
    • Peer to peer sync from desktop to desktop
    but my app does not require this at the moment. I'm sure that others may find it useful though.

    If the Microsoft.Synchronization.Data.Peer namespace from Sync Services for ADO.NET 2.0 were implemented on Sync Services for ADO.NET (Devices), then correct me if I'm wrong but all four scenarios would automatically be supported, wouldn't they? The developer would just need to write WCF (or other) services to support the N-tier architecture, determine how peer nodes would connect (ActiveSync in my case), as well as perform the regular steps required to configure sync.

    The problems that I've had so far with the Sync framework regarding SQL Server Compact 3.5 is that it does not support out parameters, so SelectNewAnchor commands and rowcounts were a bit hard to get, but still doable.
    Wednesday, July 23, 2008 1:41 PM