Calling Synchronize() for providers with updated items causes SaveChangeAction.Create instead of UpdateVersionAndMergeData RRS feed

  • Question

  • I'm new to Sync Framework, that's why I'm working on a sample to understand it. I'm using Sync Framework Version 2.

    I've got two separate SyncProviders, each of them derived from KnowledgeSyncProvider and implementing IChangeDataRetriever and INotifyingChangeApplierTarget. Provider pA operates on a sample data store dA consisting of a generic list of items which are of type tA. Provider pB operates on a separate data store dB consisting of a generic list of items which are of type tB.

    At the beginning, provider pA is forced to insert two items in its data store, and provider pB is forced to insert two other items in its data store. After inserting these items, I call Synchronize() on the SyncOrchestrator object that owns provider pA as LocalProvider and provider pB as RemoteProvider. After this synchronization, each data store consists of four items, two of each converted during synchronization to the other type. Until this point, the code works fine.

    Now, I'm updating an item of store dA and an item of store dB. Updating means in this case setting another value for a certain string member. Both items have got the same primary key in the dataStore and the same SyncId in the MetadataStore.

    Finally, I want to call Synchronize() on the SyncOrchestrator object, but when reaching the SaveItemChange method (from INotifyingChangeApplierTarget), the SaveChangeAction argument of this method has got the value Create. I don't understand this!! I expected to get UpdateVersionAndMergeData, because I did not insert new objects to the data stores - I only updated existing items. Can you help me solving this problem? Probably I did something wrong, can you tell me what it is?

    Tuesday, April 13, 2010 1:12 PM

All replies

  • Hi,

    You should only see UpdateVersionAndMergeData if you're using constraint conflicts (which is probably beyond the stuff you're working on now), but if you've updated an item (and its metadata) correctly you should see UpdataVersionAndData.

    Just to make sure I understand your situation, you are doing the following (or something similar):

    Store A (Knowledge: A2)
    Item 1 (Version: A1) "text1"
    Item 2 (Version: A2) "text2"

    --Store B (Knowledge: B2)
    Item 3 (Version: B1) "text3"
    Item 4(Version: B2) "text4"

    Then you do a sync, and at that point both of the stores are the same:

    -- Store (Knowledge: A2B2)
    Item 1 (Version: A1) "text1"
    Item 2 (Version: A2) "text2"
    Item 3 (Version: B1) "text3"
    Item 4(Version: B2) "text4"

    After this, you modify the text of the same item on both stores (lets say Item 1, and ignore the rest of the items for now).  Then you have the following:

    -- Store A (Knowledge: A3B2)
    Item 1 (Version: A3) "A"

    -- Store B (Knowledge: A2B3)
    Item 1 (Version: B3) "B"

    At this point are you saying that you're seeing a create for item 1 when you sync?  If this is your scenario, then you should be seeing a conflict for the item followed by a SaveItemChange with a SaveChangeAction that corresponds to the resolution (shouldn't be a create).  What conflict resolution policy are you specifying for sync.

    A couple things to make sure of:

    - Make sure you are managing your metadata correctly.  You should update the item's version when you update it in addition to updating the local tick count of the knowledge.  The easiest way to do this is probably to increment your tick count each time.

    - Make sure that the text you're modifying isn't connected in any way to the sync id you're using.  Sometimes people get their data/primary keys/sync ids confused and it leads to issues like this.

    It might be helpful to try a similar test with only one item on each side or only one item period (create it on store a, sync it to b, and then modify it in both places).


    SDE, Microsoft Sync Framework
    Tuesday, April 13, 2010 6:56 PM
  • Hi, thanks for your quick reply.

    I'm doing exactly what you summarized. And yes, I'm getting SaveChangeAction.Create in the SaveItemChange method in both providers. The conflict resolution policy for both providers is ApplicationDefined. The event handler of ItemConflicting sets the ResolutionAction to ConflictResolutionAction.Merge.

    I made sure that I'm managing the metadata correctly. I'm assigning a new SyncVersion object to the changed item's ChangeVersion property. This new object receives a 0 as first argument, and the replicaMetadata.GetNextTickCount() return value as second argument. I also made sure that the text I'm modifying isn't connected to the syncId. Also, I run a similar test with only one item on each side, but the problem remains the same.

    What I first forgot to say is that the data stores in both providers use different primary key counters. Provider A's data store uses an integer value which is incremented during each insertion to the datastore. Provider B's data store uses an integer value that is assigned by the user. But Provider A's data store item type tA has got another member which is equivalent to the Primary Key of Provider B's item type tB. These members are used to compare a data record in store A to a record of store B. Could it be possible that the different primary key counters are causing the problem?

    Wednesday, April 14, 2010 8:12 AM
  • The Sync item ids for any given item must match between two stores. Can you confirm that the sync Id for the Item1 is same in both metadata stores?

    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    Wednesday, April 14, 2010 5:36 PM
  • No, the SyncIds aren't equal. They can't be equal because the datatypes of both stores set their primary keys in a different manner.


    Thursday, April 15, 2010 11:04 AM
  • egon-olsen,

    ItemID is the field which sets an item's identity. If for a given item the itemId fields on 2 replicas don't match, they are interpreted by the Sync Engine as two distinct items.

    So in your case, the engine thinks you have a new item, hence the SaveAction being CREATE

    Thursday, April 15, 2010 9:11 PM
  • Thank you for your answers.
    Friday, April 16, 2010 11:34 AM