locked
SqlSyncAdapterBuilder RRS feed

  • Question

  •  

    I have been using the SqlSyncAdapterBuilder since it auto-generates a lot of the code for you.

     

    We read a post on Code Project which states that there is a performance problem with this and hence it should not be used in production. Is this true? Also, we have a large number of tables (approx. 50) but the actual volume of changes is small. I would like to avoid using manual commands and there would be a lot of typing involved for 50 tables!

     

    Any recommendations?

     

    Thanks,

    Arshad

     

     

    • Moved by Max Wang_1983 Friday, April 22, 2011 8:06 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Tuesday, April 8, 2008 5:50 PM

All replies

  • Arshad,

     

    SqlSyncAdapterBuilder generates the queries used to get and apply changes dynamically.  For example, for each sync operation the SyncAdapterBuilder queries the database system tables to determine which columns to include in the query.  This extra set of queries adds some overhead.  This may or may not be acceptable given the requirements of your application.  Furthermore, the SqlSyncAdapterBuilder is tied to SQL Server so unlike DbServerSyncProvider, it cannot be used with any ADO.NET enabled database.

     

    If your topology is relatively small in terms of the number of clients, # of concurrent syncs, etc. and you are ok with being tied to SQL Server on the server, you might want to perform some benchmarking with the SqlSyncAdapterBuilder to determine whether or not it is going to satisfy the performance needs of your application.  We have not performed this benchmarking internally as SqlSyncAdapterBuilder was originally intended to be used by the Sync Designer.  However, if we continue to receive feedback on the desire to use SqlSyncAdapterBuilder as a run-time component, we may reconsider our positioning.

     

    Sean Kelley

    Program Manager

    Microsoft

     

    Wednesday, April 9, 2008 12:09 AM
    Moderator
  • Thanks! We will run some benchmarks and post some results later.

     

    Wednesday, April 9, 2008 7:22 PM