Manipulating the change dataset in Sync Fx

One of the most common scenario asked in the Sync Fx forum is on manipulating the changes selected during synchronization before they get applied.

For example, some sync scenarios requires the client to synchronize and download rows from the server, update the rows in the client, upload the changes back to the server and then delete them from the client without having those deletes cascaded to the server when uploading changes during synchronization.

Another scenario is where based on specific conditions,  the sync application either applies the changes as it is or modify the row in transit during the sync like encrypting them or even changing how the row gets applied like applying an update as a delete instead.

Before showing some sample codes on how to go about these types of change manipulation, let’s briefly talked about how Sync Fx actually tracks or transmits these changes.

Sync Fx loads the changes to be synchronized in a dataset. To differentiate Inserts, Updates and Deletes, Sync Fx sets the RowState of each row to either Added, Modified or Deleted:

DataRowState.Added for Inserts
DataRowState.Modified for Updates
DataRowState.Deleted for Deletes

Please note that the RowState gets reset whenever AcceptChanges is called on the Dataset.

For example, if you decide to change a value of a particular column in the row marked by Sync Fx  for Update (DataRowState.Modified)  before it gets applied and you call AcceptChanges, the row’s DataRowState would actually be changed to DataRowState.Unchanged which would prevent Sync Fx from applying the change since it has already lost track of whether the update is an Insert or an Update.

To manipulate the changes before they get applied, we must intercept the change dataset and make our changes before allowing the dataset to flow thru and let Sync Fx do the change application.

So let’s look at a scenario where we want to apply a server Update as a Delete instead:

Code Snippet

1. void LocalDataCache1ServerSyncProvider_ChangesSelected(object sender, Microsoft.Synchronization.Data.ChangesSelectedEventArgs e)
2. {
3.   //let's check if we're synching the table we're interested
4.   if (e.Context.DataSet.Tables.Contains("WorkOrders"))
5.   {
6.    var dataTable = e.Context.DataSet.Tables["WorkOrders"];
7.    for (int j = 0; j < dataTable.Rows.Count; j++)
8.    {
9.     DataRow row = dataTable.Rows[j];
10.  
11.     // we're only interested in updates
12.     if (row.RowState == DataRowState.Modified)
13.     {
14.      // check if the status is Completed
15.      if (row["Status"].ToString() == "Completed")
16.      {
17.       // let's delete the row so it gets applied as a delete instead of applying it as an update
18.       dataTable.Rows[j].Delete();
19.      }
20.     }
21.    }
22.   }
23. }

In this example, we subscribed to the server provider’s ChangesSelected event. We then check if it’s the table we’re interested in. If it’s the table we want to manipulate the change application, we then loop thru each data row checking if it’s a row that’s marked as an Update. Assuming it’s an update, we check  one of the  row’s specific column value and if it’s a match, we delete the row from the dataset effectively changing it’s DataRowState to Deleted. Sync Fx then applies this row as a Delete instead of an Update originally.

Now on to another scenario where we want to prevent the source’s Deletes from being applied to the destination:

Code Snippet

1. void LocalDataCache1ServerSyncProvider_ChangesSelected(object sender, Microsoft.Synchronization.Data.ChangesSelectedEventArgs e)
2. {
3.   //let's check if we're synching the table we're interested
4.   if (e.Context.DataSet.Tables.Contains("WorkOrders"))
5.   {
6.    var dataTable = e.Context.DataSet.Tables["WorkOrders"];
7.    for (int j = 0; j < dataTable.Rows.Count; j++)
8.    {
9.     DataRow row = dataTable.Rows[j];
10.  
11.     // we're only interested in updates
12.     if (row.RowState == DataRowState.Deleted)
13.     {
14.           // let's delete the row so it doesn't get sent
15.              dataTable.Rows.Remove(dataTable.Rows[j]);
16.      }
17.    }
18.   }
19.  
20. }

In this example, we check if the row is tagged as a Delete, and then we remove it from the dataset. Please note that we used Remove instead of Delete.

Here’s another example where we change the actual column value in the row:

Code Snippet

1. void LocalDataCache1ServerSyncProvider_ChangesSelected(object sender, Microsoft.Synchronization.Data.ChangesSelectedEventArgs e)
2. {
3.   //let's check if we're synching the table we're interested
4.   if (e.Context.DataSet.Tables.Contains("WorkOrders"))
5.   {
6.    var dataTable = e.Context.DataSet.Tables["WorkOrders"];
7.    for (int j = 0; j < dataTable.Rows.Count; j++)
8.    {
9.     DataRow row = dataTable.Rows[j];
10.  
11.     // we're only interested in updates
12.     if (row.RowState == DataRowState.Modified)
13.     {
14.      // check if the status is Completed
15.      if (row["Status"].ToString() == "Completed")
16.      {
17.        //let's change the row value
18.          row["Status"] = "For Archiving";
19.      }
20.     }
21.    }
22.   }
23.  
24. }

Note that in all examples, we didn’t invoke AcceptChanges as it would effectively wipe out the row states that Sync Fx uses to differentiate Inserts, Updates and Deletes.

Intercepting and manipulating the change dataset can be done either on the local or the remote provider.

Also note that we are doing the manipulation before the changes get’s applied, in this case using the ChangesSelected event. You may also use the ApplyingChanges event to intercept the change dataset.

Hope this helps.

Cheers!