After restore from backup and SqlSyncStoreRestore, Violation of PRIMARY KEY RRS feed

  • Question

  • Happens at when tracking tables in peer1 has  metadata information. peer 2 does not have the metadata but has the records inserted in base tables with the PK value.

    Sync framework try insert and fails then raises the Apply Change Failed Event -> type of. DbConflictType.ErrorsOccurred.

    Do i need to handle this type of conflict alone in this event? Or did i do something wrong at the provisioning the server?

    Steps that i do in making the synhronization is:

    1. step provision server, into the tracking tables not whole data was copied but filtered data.

    2. backup, then restore on peer 2

    3. Calling SqlSyncStoreRestore on peer2. and then Synchronize().

    I  can handle the conflict here its just strange that there is no logic to handle this scenario. This can also happen when calling PerformCleanUp(). or not? Just want to understand the internals more. And what would be best trying to delete the record from peer2 base table if not success the manually insert the record into the peer2 tracking table...?

    Regards M

    Wednesday, September 5, 2012 9:44 AM

All replies

  • can you check the actual error, afaik, a PK violation will be reported as a LocalInserServerInsert / LocalInsertRemoteInsert conflict, not an ErrorsOccured
    Wednesday, September 5, 2012 10:30 AM
  • Detail about the error:

    e.Conflict.ErrorMessage:   "Violation of PRIMARY KEY constraint 'PK_...'. Cannot insert duplicate key in object '...'.
    The statement has been terminated." ; More details: Cannot insert duplicate key row in object '...' with unique index '...'. The duplicate key value is  ...  ...

    and e.Conflict.Type is  DbConflictType.ErrorsOccurred.

    Regard M

    Wednesday, September 5, 2012 12:48 PM
  • ok. got it.

    when you provisioned, back up and restored the database, the sync knowledge is empty.

    try synching it once before doing a backup, restore, and performpostrestorefixup

    Wednesday, September 5, 2012 1:38 PM
  • Thank you.

    What is it better in this scenarion if the database that we will backup and later introduced into the sinhronization iwhen it  contains data.

    To provision it with SetPopulateTrackingTableDefault to DbSyncCreationOption.CreateOrUseExisting or to Skip creation of the tracking table? Then backup, restore on another location run performpostrestorefixup...

    As i see it the problem is that the peer 1 contains metadata the backup later peer 2 does not but base table data is there. So this can happen if you Skip the creatin of tracking data, and in the mean time the database peer 1 is alive and gets new data inserted and with that metadata...

    Thursday, September 6, 2012 6:15 AM
  • the problem is not with the tracking table, its with the sync knowledge.

    tracking table simply stores what was changed, not what was synched. only a sync will populate the sync knowledge columns.

    Thursday, September 6, 2012 6:40 AM