none
Does “Synchronize tables in a single transaction” option roll back server changes on a failed sync? RRS feed

  • Question

  • SyncFramework 2.1; WCF; Client is a PC; SQL 2008 with Change Tracking

     

    The designer has an advanced option for “Synchronize tables in a single transaction” which I have selected.  I presumed (obviously wishful thinking) that the whole batch would be either committed or rolled back … both on the server and on the client.

     

    What actually happens is that when I perform a sync that fails (ex: lost cell connectivity), the client gets a message that says the sync is being rolled back … the server does not get rolled back.

     

    Questions:

    -          Is the intended functionality of SFx transactions to roll back all changes (client and server)?

    -          If yes, is there coding I need to implement to make this happen (I don’t see anything in the designer-generated SQL that implements SQL transactions)?

    -          If no, any suggestions on how I can implement a “safe” all or nothing sync?


    Friday, April 29, 2011 6:53 PM

Answers

  • As both JuneT and Dong said, the clientSelect-ServerApply ( upload phase of bidir sync ) and the serverSelect-ClientApply ( download phase of bidir sync) had different application transaction scope and targets so the bidir sync cannot be an "all or nothing".

    the situation you described above seems not right though. if i understand it correctly, you saying the client side changes were sent to the Server again after the failures at the download phase at the client. can you check the table/rows were not touched by other process ?

    if not, I would get more information about this case, it would be helpful if you can get:

    1. the sentAnchor at the client before the sync.
    2. the sentAnchor at the client after the sync failed due to failures at the download phase.
    3. if you can enable trace ( you can refer to this link http://msdn.microsoft.com/en-us/library/cc807160.aspx ) to enable the trace at the client side and share out the trace file, it would provide enough info for us to nail this down.

     

    thanks

    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, May 3, 2011 5:59 AM
    Moderator

All replies

  • afaik, the local and remote provider's transaction are independent of one another. so the setting works independently on each of the providers.
    Saturday, April 30, 2011 2:18 AM
    Moderator
  • That is what I think I see in the code too ... anyone got any ideas on implementing an "all or nothing" sync?

    Monday, May 2, 2011 4:37 PM
  • Hi,

    I assume that your sync direction is SyncDirection.Bidirectional. In this case, there are two separate change apply transactions on client and server sides. We don't have a way to merge them as one transaction.

    It is understandable to expect a "all or nothing" sync for one database, but I call tell the reason for your request. When transaction rollback in client side only, another successful sync should download same set of data to client. Why you want to rollback server transaction in this case?

    Thanks,
    Dong


    This posting is provided AS IS with no warranties, and confers no rights.
    Monday, May 2, 2011 7:48 PM
    Moderator
  • Yes it is Bidirectional.

    I am ending up with client inserts being applied on the server in duplicate.  It appears that the client successfully inserts a record prior to a sync failure ... on the next sync following the failure, the same record is re-inserted - presumably because the client's roll-back puts the client data in a state where it does not know the server already inserted the record.  I don't know if this is possible ... but this is how I am interpreting what I am seeing.

    Of note is the fact that I have modified the designer-generated SQL to filter records and also to implement server-side generated key field values - so I am looking at this code too ...

    Thanks!

    Monday, May 2, 2011 8:13 PM
  • As both JuneT and Dong said, the clientSelect-ServerApply ( upload phase of bidir sync ) and the serverSelect-ClientApply ( download phase of bidir sync) had different application transaction scope and targets so the bidir sync cannot be an "all or nothing".

    the situation you described above seems not right though. if i understand it correctly, you saying the client side changes were sent to the Server again after the failures at the download phase at the client. can you check the table/rows were not touched by other process ?

    if not, I would get more information about this case, it would be helpful if you can get:

    1. the sentAnchor at the client before the sync.
    2. the sentAnchor at the client after the sync failed due to failures at the download phase.
    3. if you can enable trace ( you can refer to this link http://msdn.microsoft.com/en-us/library/cc807160.aspx ) to enable the trace at the client side and share out the trace file, it would provide enough info for us to nail this down.

     

    thanks

    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, May 3, 2011 5:59 AM
    Moderator