Demo IV conceptual question: conflicts raised on both server and client? RRS feed

  • Question

  • According to the BOL topic "How to: Handle Data Conflicts and Errors" (emphasis mine):

    "...conflict detection and resolution are performed independently at each node.... Consider the following example:

    1. A row is updated at the client and the server.

    2. During the upload phase of synchronization, the DbServerSyncProvider tries to apply the client row at the server, but a conflict is detected. You resolve the conflict in favor of the server.

    3. During the download phase of synchronization, the SqlCeClientSyncProvider tries to apply the server row at the client, but a conflict is detected. The client does not recognize the row as the result of a previous conflict resolution at the server. It only detects it as a row that is in conflict. Typically, you would resolve the conflict in favor of the server so that the row would be the same at both nodes, but there is no requirement to do this."


    I have re-downloaded demo IV because I am still unclear on this concept. Here is what I have observed in the case of an update-update conflict:

    1. Choose "Abort" on server, no changes applied to client or server. This makes perfect sense to me.

    2. Choose "Force" on server. Client changes are applied to server, no conflict detected on client. This also makes perfect sense to me.

    3. Choose "Continue" on server. No changes are applied to server. This part makes sense to me, but when the changes are subsequently downloaded to the client, no changes are detected and the client's changes are overwritten. Based on the above, shouldn't a conflict arise on the CLIENT??? If not, when exactly does a client get a conflict? Is the documentation in BOL wrong, or am I reading it wrong?


    Thanks. Sorry to be thick, but I am confused. I only modified the downloaded sample in a few ways:

    1. I changed the default value for the server machine text box to ".\sqlexpress"

    2. I made the where clause updates mentioned in the other thread about demo iv.

    • Moved by Max Wang_1983 Friday, April 22, 2011 9:09 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Thursday, December 20, 2007 2:50 PM

All replies

  • Hi Stephanie,


    This behavior for (3) is expected. Think about what the client knows, it knows that i has sent the changes to the server and thus the server knows about all the conflicts thus the change coming back from the server cannot be a conflict.


    However, you get a chance to inspect the conflicts on the client through the SyncProgress events which will fire with the batch progress object showing the conflicts that was not resolved on the server.


    Check out my blog post on conflicts for more info.



    Friday, December 21, 2007 2:22 AM



    I read the blog post, and am still confused as to when a conflict DOES arise on the client. Any help would be appreciated. Is the BOL topic I quoted above incorrect?




    Wednesday, January 2, 2008 12:51 PM
  • 1. You are using bi-directional sync direction in your application, right?

    2. If you change to DownloadOnly sync direction and made a UPDATE on the same row from the server and client side, you should see Update/Update conflict from the client side conflict handling xxx_ApplyChangeFailed().



    This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, January 3, 2008 7:04 PM

    Thanks - I see the conflict on the client using DownloadOnly now. I was using Bidirectional.


    The BOL topic pretty clearly talks about having a conflict on both the server and the client. I am not seeing any scenarios in which the conflict arises on both... but I think I can use DownloadOnly to accomplish my goals.


    What I am trying to solve must be a fairly common problem:

    1. A number of clients sync with a central server. No edits are made directly on the server (just via clients).

    2. Typically, clients modify different rows, so no problems.

    3. Occasionally, clients may modify the same data, requiring custom conflict logic (some system logic, some user intervention). Because there are no users on the server directly, I have to do resolution on a client.


    I had envisioned getting the conflicts on the server and in that event handler not "resolving" the majority of the conflicts, but placing the record in a "merging" state on the server. Then, using those conflicts on the client, I could allow the system and user to resolve them, and re-sync. Then the record would come out of the "merging" state.


    Instead, I can do a download only first, resolve any conflicts on the client, and then do the bi-directional sync. If any conflicts arise on the server then, I'll have to fail and repeat the process. This feels a little convoluted, but if that's the way it's designed it should work fine. Is that more in line with the design?



    Friday, January 4, 2008 5:03 PM
  • Even though you do not have user monitor the server activity, the Sync application can still resolve conflict(s) on the server side through server conflict handler(s).  In general, we recommend using server side conflict handling for bi-directional sync application.


    Let us reveal a little bit why you did not see update/upadte conflict on the client side in your previous bi-directional scenario. 

    The client provider has its own version/anchor to track the data change on the client side.  Assume from the last sync, the local anchor is 10.  The client made a update on row id = 1 and the current local version bumps to 11.  Server made the update on the same row.  In bi-directional sync, upload is executing first.  The client provider enumerates change beyong last anchor (10) and gets changes on version 11 and sent to the server.  The server provider does nothing on this conflict and let it go.  Right before the upload completes, the client provider thinks it is done for sending its change(s) so it "remembers" the last sync anchor to be 11 (not 10 any more).  Then download is executed and the server update on row id = 1 is enumerated and sent to the client.  Since there is no change after local last sync anchor 11, this server update is applied successfully with no conflict.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 4, 2008 7:47 PM
  • Thanks, that explanation helps!


    Can you expand a little more on how conflicts could be handled on the server? I understand how to hook in code to handle the really easy conflicts, but if I have a true update-update conflict (one user updated the value from $1m to $1.2m, and the other updated $1m to $1.25m), I have to involve a user to decide which updates should win, and I have no capability of user interaction on the server.


    Monday, January 7, 2008 2:01 PM
  • Do you have any programatic way to decide which one you would like to honour, the first update or later update?  I suggest you build a business logic to solve this type of issue.  Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, January 14, 2008 7:59 AM