locked
Upgrading to SyncFramework 2.0 for peer to peer scenario over WCF RRS feed

  • Question

  • I've implemented a peer to peer sync solution that synchronizes two sql server databases.  The two databases do not have identical schemas and I'm using a decoupled tracking system.  All of this was done with the sync Framework v 1.0 along with sync services for ADO.net 2.0.  I wanted to upgrade to the newest version so that I could take advantage of the batching support.

    Are there step by step instructions or some documentation around the key differences between version 1 and version 2 of the sync framework?  I built most of my code based on the original documentation and some help from Mahjayar's blog post here: http://blogs.msdn.com/mahjayar/archive/2008/06/25/getting-started-with-dbsyncprovider-peer-to-peer-synchronization.aspx.  When I look through the documentation and examples for the new version a lot of things have changed and different verbiage is used and I'm unclear as to how to proceed.  I'm assuming that I need to follow the examples for the collaboration scenarios.  Do I still use the DBSyncProvider or should I switch over to the SqlSyncProvider.  What are the key differences? 

    Some of the setup scripts in the documentation show the table structures for the sync tracking tables and they are very different from the examples originally posted.  The same holds true for the standard stored proces used to insert and update the metadata. 

    I was hoping that everything would just work with the new version.  I did have to tweak a few things and I had to implement the code to upload the batch files but I was pleasantly surprised when everything just seemed to work.  Unfortunately things quickly came to a grinding halt and the synchronization with batching is extremely slow, which makes me think that something isn't configured quite right.  Can anyone offer some pointers here?  If I look at sql server profiler I'm seeing 3 sql statements for every row inserted - the insert into the main table, the insert into the tracking table, and then a call to update the tracking table (I don't remember this beeing the case before). 
    • Moved by Max Wang_1983 Thursday, April 21, 2011 10:50 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Friday, October 23, 2009 9:23 PM

Answers

  • Hi,

    In order to support the new features added in Sync Framework v2.0, the metadata table schema and the SQL commands have a number of changes. If you plan to continue using DbSyncProvider, please follow the MSDN link: http://msdn.microsoft.com/en-us/library/dd918682(SQL.105).aspx to update your sync solution.

    SqlSyncProvider provides management APIs to generate the metadata tables and SQL commands for your SQL Server database, and it is very easy to create a SqlSyncProvider instance by avoiding manually adding SyncAdapters. But for your scenario, it may not be the choice because SqlSyncProvider only supports data table name mapping but not column name mapping. You mentioned that your two databases have different schemas. If the column names are different as well, you have to use DbSyncProvider.

    Thanks,
    Dong
    This posting is provided AS IS with no warranties, and confers no rights.
    Tuesday, October 27, 2009 5:05 PM
    Moderator

All replies

  • Hi,

    In order to support the new features added in Sync Framework v2.0, the metadata table schema and the SQL commands have a number of changes. If you plan to continue using DbSyncProvider, please follow the MSDN link: http://msdn.microsoft.com/en-us/library/dd918682(SQL.105).aspx to update your sync solution.

    SqlSyncProvider provides management APIs to generate the metadata tables and SQL commands for your SQL Server database, and it is very easy to create a SqlSyncProvider instance by avoiding manually adding SyncAdapters. But for your scenario, it may not be the choice because SqlSyncProvider only supports data table name mapping but not column name mapping. You mentioned that your two databases have different schemas. If the column names are different as well, you have to use DbSyncProvider.

    Thanks,
    Dong
    This posting is provided AS IS with no warranties, and confers no rights.
    Tuesday, October 27, 2009 5:05 PM
    Moderator
  • Thanks,
    I was reading through that documentation earlier and I'll have to study it some more.  I guess I was hoping there was some document out there specific to upgrading that more precisely outlined the changes made to the Framework and what kinds of changes needed to be made to existing code and procedures in order to upgrade to the new version.  I'll just post additional questions as I hit them. 

    The issue that I initially encountered with the performance problem was primarily around the order in which the framework calls the the commands on a syncAdapter.  In the original version, the InsertCommand was executed, followed by the UpdateMetadataCommand.   Now, the InsertCommand is executed followed by the InsertMetaDataCommand.  In my case this was causing a constraint failure because the row in the tracking table had already been inserted by the Trigger on the base table.  The failure must have been trapped internally by the framework because it then executed the UpdateMetadataCommand.  Once I updated the procedure that handles the metadata insert to expect this behavior, the sync performed much better and the additional execution of the UpdateMetadataCommand no longer happened.
    Tuesday, October 27, 2009 8:55 PM