locked
Create additional non synchronized data RRS feed

  • Question

  •  

    We have a client server synchronization application using a WCF service to handle the synchronization calls to the server.

     

    On the client we have a requirement to create non synchronized data which as I mentioned in an earlier post was included in the table schema however the issue with this was any changes to the data in the column would cause the record to be flagged for synchronization.

     

    The approach we have now is to have a child table containing the client specific data which is not to be sent to the server which works fine but what I want to do now is make a more elegant implementation which will create the child record when the parent record is inserted rather than doing a blanket update after a sync. I am currently looking to override the ApplyInsert method on the SqlCeClientSyncProvider which is the base class for our custom provider. If someone has been here before I would be interested in hearing how you tackled it or if anyone could point out any potential pitfalls.

     

    Thanks,

     

    Bro Num

    • Moved by Max Wang_1983 Friday, April 22, 2011 7:50 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Monday, April 28, 2008 10:49 AM

Answers

  • it is possible to hook up with the ApplyingChanges or ChangesApplied Event to update/create the rows in the child table ( which contains the non-sync data, I assume ) ?

     

     

    thanks

    Yunwen

    Sunday, May 4, 2008 4:41 PM
    Moderator

All replies

  • it is possible to hook up with the ApplyingChanges or ChangesApplied Event to update/create the rows in the child table ( which contains the non-sync data, I assume ) ?

     

     

    thanks

    Yunwen

    Sunday, May 4, 2008 4:41 PM
    Moderator
  • Thanks Yunwen,

     

    That's what we have done. Initial what I had hoped to do was to add the data to the returned dataset but because the table wasn't in the downloaded schema that didn't work, I did think about doctoring the schema on the schema event but I think the implementation would have been unclean and hard to understand. Ultimately we used both of the events you describe above to apply data in different cases and tied into the transactions provided in the events to ensure changes were rolled back.

     

    Bro Num

    Tuesday, May 6, 2008 11:21 AM