locked
N-Tier ApplyChangeFailed Problems RRS feed

  • Question

  • Hello,

     

    we are using the ADO.Net Sync Services for our current project.

    We use the  N-Tier model as our topolgy (instead of the two tier model). The code was generated for us by the new Sync Winizard of Visual Studio 2008. The synchronisation works fine but we have a problem with conflicts. We have registerd both on the server and the client the 'ApplyChangeFailed' event. If we change the same row on the server and on the client and sync afterwards, the ApplyChangedFailed event is raised on the server but not on the client. We read on the following forum:

     

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2322781&SiteID=1

     

    that the event should be posted to the client, if i don't register it on the server. We did, that but the ApplyChangedFailed event is not posted to the client. So we think this is a bug in the current ADO.Net Sync services or isn't it? Does anybody know any solution or has experience with the topic?

     

    We would be very happy about any kind of input.

     

    greetings

     

    Andreas

    • Moved by Hengzhe Li Friday, April 22, 2011 3:13 AM (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Friday, May 9, 2008 3:27 PM

Answers

  • thanks for re-surfacing this issue. I almost dropped it.

     

    For the issue discussed previously in this thread ( if server side chooses server win, client side won't have conflict event raised ). I have chatted with other folks and this is by-designed behavior-- i.e. the client will just apply the row from server assuming this is already resolved. if we do want the behavior as described in the mail, other do a download first, or do a dummy update of the conflicting row would be a way to achieve it ( yes, for a ntier config, this could be chanllenging ).

     

    client side conflict may seen under the following cases, I think that would be usefule to understand it.

    1. downloading sceanrions

    2. client side changes during the sync, e.g. some changes occurs after upload time but before download time.

     

    Thanks

    Yunwen

     

    Sunday, July 13, 2008 4:58 PM
    Moderator

All replies

  • I have forgotten to say, that we have extended the code wo work for bidirectional synchronization(in the partial class that is offerd by Visual Studio for that purpose), so that is not the problem.

     

    greetings

     

    Andreas

    Sunday, May 11, 2008 12:45 PM
  •  

    what conflict resolution are you using in your project ? if you are using ServerWin, the server change should be sent to the client and a conflict should be raised on client. if you use ClientWin to resolve the conflict on server, then there should not be changes sent to the client since the client data was end up on the server.

     

    could you elabrate you case with some details ?

     

    thanks

    Yunwen

    Tuesday, May 13, 2008 12:39 AM
    Moderator
  • Hi Yunwen,

     

    thank you for your help. I have now set one member of the ConflictResolver on the ClientSyncProvider explecitly to ServerWins, like that: 

    this.ConflictResolver.ClientUpdateServerUpdateAction = Microsoft.Synchronization.Data.ResolveAction.ServerWins;

     

    Afterwards I made a change on the client and on the server. I still get the ApplyChangedFailed event on the server and not on the client. You said that the event should fire on the client, or I am wrong?

     

    thanks

    Andreas 

     

    Wednesday, May 14, 2008 7:28 PM
  • It is expected to this excepton on the server since the sync will upload the client change to server first and hence the conflict on server. based on your own business logic, you can resovle this conflict on server ( with your own logic and code ) in the ApplyChangeFailed Event. if Server win will be your choice, then the client change will be discarded on the server and the server change should be sent to the client during the downloading phase of the sync and you can resolve it as serverWin ( basically forcefuly apply the server change on client ). by doing this ( by your code and by the sync service code ), the data will be convergent on both server and client.

     

    so you didn't do anyting wrong, I think you just need to implement the server side conflict code to make the solution complete.

     

    thanks

    Yunwen

    • Unmarked as answer by Hengzhe Li Friday, April 22, 2011 3:12 AM
    Friday, May 16, 2008 12:27 AM
    Moderator
  • Hi, Yunwen

     

    thank you for your help!

     

    the problem is that we can not handle the ApplyChangedFailed events on the server. The reason for this is, that no person is sitting in front of the server to handle the conflicts. We want the conflict to be handled on the client, so that in an ApplyChangedEvents(there are two as you know) on the client machine we open a dialog (which blocks the event) and allows the user to handle the conflict appropriatly(by using the events args-parameter). I think handling the conflict on the server with some business logic is not possible in our case, we need human feedbackSmile So the problem is still how can we manage to raise the ApplyChangeFailed event on the client and not on the server. 

     

    thanks

     

    Andreas

     

    Friday, May 16, 2008 1:58 PM
  • Hi,

     

    let me add the link here to a thread for the same problem in this forum:

    http://forums.microsoft.com/Sync/ShowPost.aspx?PostID=2396149&SiteID=75

     

    I really think there is a bug in the Sync Services for ADO.Net in the current implementation at the ApplyChangedFailed-event on the client. This event does fire only at ClientInsertServerInsert-Conflict.

     

    Can anyone help us?

     

    thanks

     

    Andreas

    Friday, May 30, 2008 9:53 PM
  •  

    I see.

     

    before we go further to explore other possible solutions for your case, is it possible to seperate the bidir sync in you all for a download, and then followed by a upload ?

     

    the reason the conflict was handled on the server side is due to upload always occurs first in a bidir sync.

     

    thanks

    Yunwen

    Saturday, May 31, 2008 11:47 PM
    Moderator
  • Hi Yunwen,

     

    we know that upload always occurs first. So when we make a change on the same datarow on the client and on the server we get the ApplyChangeFailed event on the ServerSyncProvider first. In the even we have two options to choose from,

    - to apply the client change at the server  or

    - to continue without an Action.

     

     If we choose continue the server should download the server datarow to the client and at the client side the ApplyChangeFailed event of the ClientSyncProvider should(!!!) fire but it does not! The datarow of the server overwirttes the datarow of the client without any ApplyChangeFailed event. We also have set

    the ConflictResolver.ClientUpdateServerUpdate at the ClientSyncProvider to FireEvent which is the default anyway so this event must fire. I dont understand why not.

     

    What do you mean with separate in download and upload. If we change the sync-strategy, an we do download first, I think the client changes will be ovewritten or deleted.

     

     

    thanks

     

    Andreas

     

     

     

     

    Monday, June 2, 2008 1:39 PM
  • Hi everybody,

     

    First of all I have to say that I am quite new in the area of the sync services.

    In the last days I played around a little bit with the framework and as far as I can see it's quite good. Now I am looking into the conflict handling. I tried serveral things, but as Andreas already described I am not able to manage the synchronization (and the ApplyChangeFailed-Event) on the client too.

     

    Have you found a solution for the problem? Please let me know if you made any progress?

     

    Thanks,

    Andrea

     

     

     

    Wednesday, July 2, 2008 7:11 AM
  • thanks for re-surfacing this issue. I almost dropped it.

     

    For the issue discussed previously in this thread ( if server side chooses server win, client side won't have conflict event raised ). I have chatted with other folks and this is by-designed behavior-- i.e. the client will just apply the row from server assuming this is already resolved. if we do want the behavior as described in the mail, other do a download first, or do a dummy update of the conflicting row would be a way to achieve it ( yes, for a ntier config, this could be chanllenging ).

     

    client side conflict may seen under the following cases, I think that would be usefule to understand it.

    1. downloading sceanrions

    2. client side changes during the sync, e.g. some changes occurs after upload time but before download time.

     

    Thanks

    Yunwen

     

    Sunday, July 13, 2008 4:58 PM
    Moderator
  •  

    what conflict resolution are you using in your project ? if you are using ServerWin, the server change should be sent to the client and a conflict should be raised on client. if you use ClientWin to resolve the conflict on server, then there should not be changes sent to the client since the client data was end up on the server.

     

    could you elabrate you case with some details ?

     

    thanks

    Yunwen


    I'm using Server Wins (ApplyAction.Continue) when the conflict is raised on the server, the Server change is applied but no conflict is ever raised on the client. I only get the number of conflicts in the SyncStatistics result from calling the Synchronize() method.
    Thursday, May 28, 2009 4:59 PM