none
Complex Sync scenario: possible with Sync Services? RRS feed

  • Question

  • Hi

    I'm working on a project which includes several handheld scanners connected to multiple servers.I'll try to explain it a bit clear:

    Each store in our company (around 100) has its own 'store server', which database can have different data depending on the type of store (different prices, PLU's, ... but the table structure remains the same). I want to set up a synchronization between this server and the scanners in the store, because they also have to be able to work offline. (Each 'store server' also connects to the production server, and uploads the barcode scans from the store, but that's not my concern)

    This is all possible with the Sync Framework, but the problem is: it has to be possible to take any scanner from one store and use it in another.

    For the 'DownloadOnly' data (prices, PLU's, product codes, ...) this is no problem because I could simply do the sync again and get the right rows. For the 'UploadOnly' data (e.g. the scanned barcodes) this is a problem because every barcode scan has to get on a 'store server' just once (it doesn't really matter which 'store server', it just has to reach the production server).

    I don't think there's a way to know if a row already has been uploaded, without being connected to that particular server. Also it has to be possible to delete the last 6 barcode scans, from the scanner, in case of errors. This is off course impossible when you're connected to another store server than the server containing the deleted row.

    Any ideas on this? I have a strong feeling this won't be possible at all using the Sync Framework, but maybe some ideas could help me further.

    Thanks in advance

    Joachim


    Monday, June 20, 2011 3:09 PM

All replies

  • what's the OS on your barcode scanners?

    if it's WM 6.5, then you dont have much choice in terms of the provider you can  use other than the SqlCEClientSyncProvider and it doesnt support peer to peer sync, just hub-spoke sync.

    Now, assuming you can run the newer SqlCESyncProvider or SqlSyncProvider, they allow for peer-to-peer synching. so you can sync it with any other peer for as long as you have the same scope definition.

    you can take a Scanner 1 to sync with Server 1 and Server 1 syncs with Central Server. 

    assuming you have Server 2 and it has synched (bidirectional) with Central Server, it will pick up the changes from Server 1 (originally from Scanner1) and apply it to itself.  now if you sync Scanner 1 with Server 2, the "sync knowledge" would know that the rows synched by Scanner 1 to Server 1 has been applied to Server 2 already and wont sync it again.

    assuming Server 2 hasnt synched with Central, then you sync Scanner 1 with Server 2, Server 2 would apply the changes to itself. Now when Server 2 syncs with Central Server, the sync knowledge in Central Server would know that it already has those changes (it got the changes from Server 1) and wont apply it.

    in effect, a sync destination only applies a change once.

    Tuesday, June 21, 2011 1:12 AM
    Moderator
  • Thanks for the answer!

    The OS on the scanners is Windows CE 5.0. We're planning to make a WM (don't know which version yet) version in the future but we have to support both.

    The store servers don't sync with the central server using sync framework. This is done by a WCF service which isn't my task (the table structure is going to be strongly simplified from central server to store server because we don't need some link tables if we know the store type).


    Tuesday, June 21, 2011 7:04 AM
  • if it's Windows CE 5, SqlCEClientSyncProvider  is the only supported provider. so you're stuck with the offline provider/hub-spoke type of sync.

    this provider is based on anchors, so you cant just switch to another server as the servers will be sending different anchors.

    Tuesday, June 21, 2011 7:17 AM
    Moderator
  • That was also my thought. Thanks for your help, I will discuss this further with my colleagues
    Tuesday, June 21, 2011 7:38 AM
  • is the Upload from scanner to store server just for inserts? if it is, you might be able to do some workaround so that if the record already exists on the server, the server record wins. meaning, the scanner upload for that row will be ignored.

    another approach would be to define your anchor as UTC date on both device and server.

    Tuesday, June 21, 2011 7:52 AM
    Moderator
  • The barcode scannings are uploadonly, I need to be able to do incremental inserts, updates & deletes (for corrections). The other data will be just downloadonly (this can't be a problem because I can simply drop my table and do the sync again in another store, it doesn't happen that much).

    These are the requirements for the moment, and as long as I don't need bidirectional syncs I'm thinking maybe its indeed possible with some workarounds (and better then writing the whole synchronization myself).

    The only problem I see is if there still exists some uploadonly data on the scanner from one store (could be an insert, update, delete), when it's already taken to another. An insert wouldn't be a problem because we could check the ID in the 'store server' --> 'central server' step. (however I think if we use UTC date as anchor, this won't be neccesary). So updates and deletes are the problem

     


    Tuesday, June 21, 2011 8:13 AM
  • updates and deletes should work as well with the UTC i think. just try to handle things in the ApplyChangeFailed event.

    for example if you have an update on the scanner and you take it on another server that doesnt have the row to be updated, you can do an insert instead of an update.

    not sure how you handle deletes, but you can try doing logical deletes instead via a deleted flag instead of a physical delete.

    Tuesday, June 21, 2011 8:25 AM
    Moderator
  • Thanks for your info. I'm hoping it's not a problem that some barcodes scannings will be on a store server twice. I think that's something the 'store server --> central server' sync will have to handle anyway.
    Tuesday, June 21, 2011 8:39 AM