locked
Possibility to synchronize tables in a one-to-many scenario? RRS feed

  • Question

  • I've got the following scenario: SyncProvider A operates on a table with a certain primary key column. SyncProvider B operates on another table where the primary key column is other than the Provider A's PK column. With other words, both tables' PK columns don't match.

    Provider B's table has got another column (no key column) that can have values of the same type and range as Provider A's PK column. But this column in Provider B's table has no unique constraint, meaning that values in that column can appear more than once.

    With other words, between Provider A's table and Provider B's table there is a 1:n relation. That means that during synchronization, updating a record in Provider A's table should lead to updating all the corresponding records in Provider B's table.

    Apparently, Sync Framework doesn't support this one-to-many synchronization, but nevertheless I'm searching a solution for this problem. Do you have any idea for solving this problem?

    P.S.: I know that both providers' tables should have the same primary key columns, but in my case this is impossible to reach.

    Wednesday, April 21, 2010 12:56 PM

All replies

  • Hi Egon,

    As you mentioned this is definitely not supported scenario in the relational providers. I am also not sure I can think of a solution off the top of my head for the scenario where a row from one replica will update multiple rows on the other side. What is your scenario that is causing the table schema to be different in the two replicas?


    Maheshwar Jayaraman - http://blogs.msdn.com/mahjayar
    • Proposed as answer by Jandeep Wednesday, May 5, 2010 8:38 PM
    Wednesday, April 21, 2010 5:55 PM
  • Hi mahjayar,

    in my scenario the structures of the tables of both providers are heterogeneous. The table where more than one records of this value can appear has got other columns to differentiate between these records. Because of this, the table should be normalized, but this is impossible as the table's structure can't be changed, because it is used by lots of other applications in my company.

     

    Thursday, April 22, 2010 7:31 AM