locked
Issue with records moving into scope not being synchronised RRS feed

  • Question

  • We are developing a one-directional database sync system based on Sync Framework 2.0 with a WCF sync service and (for the moment) a Windows Forms test client.  There is a SQL Server 2005 database at both ends and we are using SqlSyncProviders.  The client uses a SyncOrchestrator (in a new MTA thread) to carry out the synchronisation.

    Database provisioning is carried out in a one-off precursor stage using a SqlSyncScopeProvisioning object.  There are row filters to restrict the synchronisation scope to a subset of the records in a given table.

    This all works satisfactorily.  However, our QA department has reported a potential problem with the synchronisation.

    When an in-scope record is created at the source, it is subsequently synchronised to the destination.  If it is edited to remove it from scope, it is not then synchronised.  If it is again edited, this time bringing it back into scope, it is again subsequently synchronised.  So far, so good.

    But, if an out-of-scope record is initially created in the source, a change does not appear to be applied at the destination on synchronisation following an edit at the source to bring it into scope.

    Is this behaviour to be expected when using the sync framework?  If so, is it a defect?

    Thanks.

     

     

    Wednesday, May 5, 2010 8:07 AM

Answers

All replies

  • i'm guessing the out-of-scope row which was updated to bring it in scope is being detected as an update, so its being applied as an update on the client. The update would fail because the row was not previously downloaded to the client.

    can you confirm if you're not getting conflict errors?

    Wednesday, May 5, 2010 11:52 AM
  • i'm guessing the out-of-scope row which was updated to bring it in scope is being detected as an update, so its being applied as an update on the client. The update would fail because the row was not previously downloaded to the client.

    can you confirm if you're not getting conflict errors?


    Thanks for your reply.  Yes, that would make sense.

    I've just carried out a test and can confirm the following:  

    1. Out-of-scope record created at source - not synchronised to destination

    2. The record is updated at source to bring it into scope - SyncOperationStatistics reports 1 change applied on synchronisation, but no record created at destination (although a record is created in the destination table's tracking table)

    3. The destination provider's ApplyChangeFailed event does NOT fire.

     

    Thursday, May 6, 2010 8:34 AM
  • you might want to enable Sync tracing in verbose mode to see what's happening underneath.

    Also, try to run SQL Profiler to capture the SQL SPs on the destination.

    Thursday, May 6, 2010 10:59 AM
  • Hey ,

    Records move in/move out scopes are not supported scenarios currently and are not tested. See more info at section "Filtered and Overlapping Scopes" @ttp://msdn.microsoft.com/en-us/library/dd918682(v=SQL.105).aspx .

     

    Thanks,

     


    Ann Tang
    Thursday, May 6, 2010 5:53 PM
  • Stephen,

    I have your exact scenario currently in place. 

    When a record that previously wasnt in scope and goes into scope due to a row update and is downloaded to the client the ApplyChangeFailed event in your ClientSyncProvider should fire with a conflict type of ClientDeleteServerUpdate.  You can set the action to Retry with force write to apply the row to the table.

    The event should be fired automatically but can explictly be specified as follows:

    this

     

    .ConflictResolver.ClientDeleteServerUpdateAction = ResolveAction.FireEvent;

     

     

    private void ClientSyncProvider_ApplyChangeFailed(object sender, ApplyChangeFailedEventArgs e)
        {
          switch (e.Conflict.ConflictType)
          {
              
                 //This type may occur if a row that previously didnt meet the filter criteria, now does.
            case ConflictType.ClientDeleteServerUpdate:
              e.Action = ApplyAction.RetryWithForceWrite;
              break;
    
          }
        }

     

    Thursday, May 6, 2010 6:12 PM
  • Hi G Stephen,

    The behaviour that Andrew E just posted is what i was referring to in my other post as the expected behaviour. You might want to try out Andrew's code above if you catch the conflict.

    Cheers,

    JuneT

    Friday, May 7, 2010 12:09 AM
  • Thanks everyone for your input on this.  And special thanks to Ann Tang for providing the link to the article.

    Cheers,

    Graham.

    Saturday, May 8, 2010 4:22 PM