locked
localinsertremoteinsert Keep Both RRS feed

  • Question

  • Is there going to be any enhancement in version 3 to resolve a localinsertremoteinsert conflict by Keeping Both versions i.e. from remote and local and then propagate this change to all the other referenced tables.

     

      

    Local

    Remote

    Table A

     Key

    Name

    1

    A1

     2

    A2

                                                    

    Table B

    Key

    Name

    TableAKey

    1

    B1

    1

    2

    B2

    2

     

     

    Table A

    Key

    Name

    1

    A1

    2

    A2R

                                                     

    Table B

    Key

    Name

    TableAKey

    1

    B1

    1

     2

    B2

    2

     

     

     

    Say Local TableA has record 2 inserted and remote TableA also has record 2 inserted but they are both different entities. When sync framework goes to syn these tables it finds a localinsertremoteinsert conflict but there is no way to have a 3rd record added to both local and remote tablesA and then also update table B with the new id.

    This is a very common scenario and I think Sync framework should handle it out of the box. We have an existing product whose db has been out there for last 10 years so we can not change Pks to guids to reolve this problem either.


    Aj
    Wednesday, August 4, 2010 12:53 AM

Answers

  • You can always set a guid column on the table and mark it as the "Sync Primary Key". This way your app primary keys are different from Sync primary keys. Which also means you will never have InsertInsert conflicts and instead will have constraint errors (imagining that you have unique constraints on your app primary keys) at which point you will use the ApplyChangeFailed event to do the necessary changes. FYI, Ajay's question was around using the SyncFx on both ends and not with the Asymmetric service.


    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    • Marked as answer by mjayaram Wednesday, August 11, 2010 5:06 PM
    Wednesday, August 4, 2010 6:23 PM

All replies

  • Hi Ajay,

    This scenario is something that the SyncFx and the Relational providers do support today. The asymmetric  service unfortunately does not expose the underlying sqlprovider to the user. This is something that will definitely be fixed for RTM and based on feedback might make it in the next CTP release as well. Please email me directly using the contact form if this is a blocking issue for you and we can try to think of some shortterm workarounds. 


    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    Wednesday, August 4, 2010 3:21 AM
  • We are at the moment standing in front of the same problem. We are thinking about changing to Guid. The SyncFx isn't the only reason for that. The second reason is Replication, but it would be nice to be able to sync it with integer and have the framework do the work of changing the FK in the other tables. even if this means to edit the provider.

    What im wondering about is what the problem is to change to Guid? I just a few days ago edited the northwind database to Guids without losing a single PK FK connection.

    Wednesday, August 4, 2010 6:46 AM
  • major problem for us to change to Guid is that our software presumes PK to be int and to change that in the software will be a massive amount of work. I agree that syn framework should take care of this issue.
    Aj
    Wednesday, August 4, 2010 8:08 AM
  • You can always set a guid column on the table and mark it as the "Sync Primary Key". This way your app primary keys are different from Sync primary keys. Which also means you will never have InsertInsert conflicts and instead will have constraint errors (imagining that you have unique constraints on your app primary keys) at which point you will use the ApplyChangeFailed event to do the necessary changes. FYI, Ajay's question was around using the SyncFx on both ends and not with the Asymmetric service.


    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    • Marked as answer by mjayaram Wednesday, August 11, 2010 5:06 PM
    Wednesday, August 4, 2010 6:23 PM