locked
LocalInsertRemoteInsert after De-provision/Re-provision RRS feed

  • Question

  • I have two databases (SQL Server & SQL Express) syncing using sync 2.1. Everything is good.

    To begin with I have to script changes from DEV to TST because I can't use the application to de-provision/re-provision the server as application SQL accounts don't have access to modify objects in testing.

    My issue comes into play when I have to change scope and need to migrate scope config data from my development environment to test environment.

    My release process is as follows:

    1) Compare objects from DEV to TST and script changes over. (application tables, sync tables, triggers, application stored procs, sync stored procs, everything, etc).

    2) Update scope_config data based on new scope on TST server. (now both environments should be same)

    3) In the application I run de-provision/re-provision, then sync.

    During the sync process it results in LocalInsertRemoteInsert confict. This is due to the fact that the data on the local database still exists and sync thinks it needs to be populated. I've read about SqlSyncStoreRestore.PerformPostRestoreFixup, but I don't think that's my solution. After looking at the trace log it appears the conflicting results are produced by the bulkinsert stored proc. I'm unsure as to why bulkinsert is being used and what is that trigger mechanism that makes it come into play.

    I have a feeling its due to the fact that the tracking tables are being rebuilt on the local db. Is there anything I can do to eliminate the LocalInsertRemoteInsert conflict after de-provisioning/re-provisioning only the local db?

    Thanks, Jason


    Wired4This
    Friday, August 19, 2011 8:29 PM

Answers

  • when you change the schema, the UDT and some stored procs need to be changed. if you added a filter, triggers and tracking tables need to be updated too and these changes need to be reflected in the scope_config.

    if you're fine reinitializing your client databases, deprovision, delete data, re-provision is the quickest and simpliest solution.

    • Marked as answer by Jason_Keith Tuesday, August 23, 2011 1:31 PM
    Tuesday, August 23, 2011 1:04 AM

All replies

  • when you deprovisioned the local db, you wiped out the sync knowledge. so when sync framework enumerates changes on the server, it has now way of telling if the local db has its rows already, thus its sending the changes to your local db.

    if you have a way of updating the scope config already, i suggest you use the same for the client as well and not use the deprovision/reprovision approach.

    Saturday, August 20, 2011 2:15 AM
  • Hi June thanks for the response. Yes I could update the scope config but if I were altering a table would I also have to update the sync stored procs? If so thats leading me to one of these posts below. I assume that I would need to go in one of these directions. As an alternate solution to both of the links below, could I simply delete the table data in the tables and allow sync to repopulate?

    Modifying Sync Framework Scope Definition – Part 2 – Workarounds

     http://jtabadero.wordpress.com/2011/03/24/modifying-sync-framework-scope-definition-part-2-workarounds/

     Easy solution to adapt scopes to schema changes...

    http://social.microsoft.com/Forums/en-US/syncdevdiscussions/thread/5574849a-b213-4cf5-a349-8a02bd376d29

     

     


    Wired4This
    Monday, August 22, 2011 2:54 PM
  • when you change the schema, the UDT and some stored procs need to be changed. if you added a filter, triggers and tracking tables need to be updated too and these changes need to be reflected in the scope_config.

    if you're fine reinitializing your client databases, deprovision, delete data, re-provision is the quickest and simpliest solution.

    • Marked as answer by Jason_Keith Tuesday, August 23, 2011 1:31 PM
    Tuesday, August 23, 2011 1:04 AM