none
Sync Framework 2.1 - DbServerSyncProvider ApplyChanges Method Not Syncing RRS feed

  • Question

  • Hello.  We are trying to use the ApplyChanges method of the DbServerSyncProvider class to apply changes from a dataset to a database application.  The dataset data (one table) comes from another application and the table schemas between the datatable and the SQL Server table are not the same.  We are using the column mappings property to handle the differences in schema.  We have provisioned our server database using the SqlSyncScopeProvisioning class.

    When we call the ApplyChanges method, the dataset appears to be passed to the SyncGroupProgress object successfully, however, when we examine the SyncTableProgress object the DataTable property is null.  There is only one table in our Sync Group and one datatable in the dataset we are passing to the ApplyChanges method. 

    We haven't found much information on the ApplyChanges method and wanted to know if anyone has any insight as to why the DataTable property of our SyncTableProgress object is null, or what tests we might run to locate the source of this issue.

    Thank you,

    David Lloyd
    Lemington Consulting


    David Lloyd Lemington Consulting http://LemingtonIT.com
    Monday, January 17, 2011 6:25 PM

All replies

  • without knowing some details, it is hard to say for sure. but by looking into this post, there are a couple things need to clarify:

    1. what is the SyncGroupMeta object you constructed for the ApplyChange() method ? the sync need this object to be set correctly in order to sync  the right table.

    2. what is your sync scenario ? what are the syncadapter you specify to the dbserversyncprovider instance ? it seems you used the sqlsyncScopeProvisioing class to provision the sql server db. but you use the dbServerSyncProvider which will not pair up with the provisioing work you have done.

     

    thanks

    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, January 18, 2011 9:40 AM
    Moderator
  • isnt DBServerSyncProvider for the offline scenario whereas SqlSyncScopeProvisioning  is from the peer-to-peer/collaboration provider?

    afaik, you cant mix and match those providers.

    You'll have to build your own SyncAdapters for the DBServerSyncProvider rather than provisioning the server side via SqlSyncScopeProvisioning

    Tuesday, January 18, 2011 10:49 AM
    Moderator
  • Yunwen:

    Yes, we are creating the SyncTableMetadata object and then passing this to the SyncGroupMetadata object.  Please see the sample code below.

         SyncAnchor lsa = new SyncAnchor();
         lsa.Anchor = biLastSyncAnchor;
         SyncTableMetadata stm = new SyncTableMetadata("MyServerTableName", SyncDirection.UploadOnly);
         stm.LastSentAnchor = lsa;

         sgm = new SyncGroupMetadata("MySGMName");
         sgm.TablesMetadata.Add(stm);

    Regarding the SyncAdapter and provisioning, we used provisioning to help us setup the stored procedures and table for the syncing.  We then created our own SyncAdapter and referenced these stored procedures in our Insert, Update and Delete commands (with the appropriate parameters).  We then added this SyncAdapter to the dbServerSyncProvider object prior to calling the ApplyChanges method.  We also created a SyncSchema object and passed this to the dbServerSyncProvider object prior to calling ApplyChanges.

         SyncSchema syncschem = new SyncSchema();
         syncschem.SchemaDataSet = MyDataSet;
         sp.Schema = syncschem;

    The Anchor values which show up as null in the SyncContext object even though they are populated in the SyncGroupMetaData object.  I'm not sure if this is an issue for the ApplyChanges method.  We have also tried to prepopulate the SyncGroupProgress and SyncTableProgress objects in the SyncContext object but the ApplyChanges method appears to overwrite our SyncGroupProgress and SyncTableProgress objects.

    Since the schema of the datatable and the schema of the server table are different, are there specific requirements in terms of how ColumnMappings or other properties need to be setup?  The ApplyChanges method must see the datatable in the dataset, and we only have one table in our sync group, so it acts like it is rejecting the datatable as appropriate for syncing with the server table (for schema differences or some other reason).

    Any thoughts would be appreciated.

    Thank you,

    David Lloyd
    Lemington Consulting

     


    David Lloyd Lemington Consulting http://LemingtonIT.com
    Tuesday, January 18, 2011 5:51 PM
  • you will need to ensure that the syncTables in the syncAgent.Configuration is set to that group; and the table name is the same as the syncAdapter( case sensitive ) also.

    if you still see not action was take on the table, you can enable level 4 trace and also profile the SqlServer to see if you can have more hints from there.

    thanks

    Yunwen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, January 18, 2011 10:01 PM
    Moderator
  • Yunwen:

    We checked the table name in the SyncGroupMetaData object and the datatable name in the dataset we are passing to the ApplyChanges method and they are both the same (case sensitive).

    We enabled level 4 (verbose) tracing but did not see any information we could not see in our debugging.  We tried SQL Server Profiler to see if it may be a permissions issue in the database.  However, from what we can tell, the InsertCommand, UpdateCommand, and DeleteCommand stored procedures are not being executed against the database.  The issue appears to be further upstream.

    Our assessment at this point is that either there is an issue related to the schema difference and how we are handling the ColumnMappings, or the ApplyChanges method cannot determine what inserts, updates and deletes to apply to the table from the dataset given as a parameter.

    Thank you,

    David Lloyd
    Lemington Consulting


    David Lloyd Lemington Consulting http://LemingtonIT.com
    Thursday, January 20, 2011 9:41 PM