Introduction to ADO.NET Sync Services

• Download source - 183 KB

Introduction

This article will demonstrate how easily you can design occasionally connected applications using ADO.NET Sync services. It's going to be a very basic example in VB.NET, showing how easily you can use Sync services within your application.

Background

At our organization, we have designed an application for Fire Rescue chiefs who are usually on unit and want the ability to access the application using their laptops and even PDAs. They use Verizon cards for broadband access, and it works well for the most part, but once in a while, they lose the connection and the application dies. The ability to support mobile and remote workers is becoming more and more important for organizations. The Microsoft Sync framework has been designed to address these issues, and gives a great framework to easily design your applications on occasionally connected architecture. For this article, I will use a VB.NET sample as there are very few VB.NET examples on the net.

Using the Code

I have uploaded the complete source code for the project. At the same time, I will go through the setting up step by step. Hopefully, in the process, I'll be able to explain the whole thing in detail.

First, you'll have to download the Sync framework from the Microsoft website. The V1 is available for download from MSDN.

Once the framework has been installed, start Visual Studio 2008 and create a new Windows Forms application.

Now, let's add a new item to the project, "Local Data Cache":

What this is going to do is create a local SQL CE database that will be used by the client application, and we will eventually write the code to sync up this database with our master database, for selected tables. The best part of the Sync framework is its support for Visual Studio 2008. It provides a nice wizard for the whole set up, making our life a lot easier.

As soon as you click the "Add" button, the next screen pops up, which will be used to set up your local cached database. On the screen, select "Server Connection". Now, if you have previously used the Windows Forms application, you may already have a SQL connection setup, like in my case; otherwise, click the New button and create the connection string for your master SQL Server. For this example, I will use our favorite "AdventureWorks" database. This is how the second screen looks like:

Now that you have given your server connection information, the wizard creates a client connection. This is nothing but a new SQL CE database that you have just created. Also, now that the wizard is aware of the server database, it will allow you to add the tables to be cached. Click the "Add" button on the left bottom of the screen. Once you hit the "Add" button, the following screen appears.

Select the tables that you would like to cache on the client side. Now, remember, you do not want to select all the tables as it's not practical to cache the whole master database on the client machine, as usually, the client machines in such cases as laptops, tablets, and PDAs may not have enough storage. In the above scenario, I have selected three tables. On the right side of the screen, you will get some more setting options. In most cases, you would like to keep them to the default settings.

The first option asks you what data you want to download. new and incremental changes are done only after the first synchronization. Also, the sync framework is going to add two new columns to your tables to keep track of the last update and new inserts. You can choose existing columns if you are already tracking it. Also, it will create a history table named TABLENAME_Tombstone. This is used to keep track of deleted rows. With SQL Server 2008, you would not need either of them, as SQL Server has standard change tracking. So, with SQL Server 2008, it will not add any additional columns or a tombstone table.

Select "OK", and "OK" on the first wizard screen. This will create a local cached database with the tables you selected. On the first wizard screen, you also have options to select the server and the client project location. In this scenario, both will be our current projects. In my next article, I will try to cover a three tier example of using WCF services. And, in an N tier application, you can select your server and client application to be different. You can optionally select to create synchronization components for the client only or the server only. By default, it's the client and the server.

After hitting OK on this screen, the wizard will create a local database (.sdf); in our case, it created AdventureWorks.sdf. It will then prompt you with the following screen, allowing you to select tables to be added to your dataset. This will allow easy creation of the grid on the form with a typed dataset.

As you can see, I have selected all the three tables. After clicking Finish, it will create a dataset for the project. You can open the dataset and add some more tables from the Server Explorer, but those tables will not be cached on the client machine. They will be available to use in the application, but the application will go back to the server each time those tables are accessed. For this demo, we'll keep it simple, and not add any more tables, as the main purpose of the demo is to see the sync framework in action. Now, go back to your form and open your data sources (show the data sources under the Data menu). Select the Employee table and select the DataGridView, and drag the table on the form. This should add the GridView to the form with all the navigation controls. I really like this part of the design, just drag and drop and you are ready to go.

Now comes the main part. In order to activate the sync process, we will add the button to the grid's tab strip. Usually, you will have a service running in the background that will check for network availability, and if its available, it will initiate the sync process. Again, for this demo, we will try to keep it simple, and will call the sync process on the click of a button.

Double click the button, and add the code to sync the databases. Now, it's just three lines of code, and out of those, two lines have been provided right in the wizard. Click LocalDataCache1.sync, and you will notice that on the right bottom corner is "Show Code Example"; click that, copy the code, and cut paste it in the event handler for the button click.

Now, just add code to merge the changes to the client table, using:

Me.AdventureWorksDataSet.Employee.Merge(EmployeeTableAdapter.GetData())

And that's it, your first occasionally connected WinForms application is ready to run. Browse through the data on the client side. Now, make some changes to the data on the server. The data on the client is still old as we have not initiated the sync process. Click the Sync button and your client gets updated with new data. Now, try changing the data on the client and see if it is reflected on the server. It wont as, by default, the sync works unidirectional. But again, they have made it real easy to change it to bidirectional. All you have to do is right click LocalDataCache1.sync, and select View Code. You will see the SyncAgent class; just add the following code:

Partial Public Class LocalDataCache1SyncAgent
    Private Sub OnInitialized()
        Me.Employee.SyncDirection = _
           Microsoft.Synchronization.Data.SyncDirection.Bidirectional
    End Sub
End Class

And now, your application should sync up in both directions. Try changing some data on the client side, click the "Save" button on the tool bar, and then click the Sync button. Data on the server should reflect the changes done on the client side; but wait, have we got us in trouble by allowing bidirectional sync? What happens if both the client and the server update the same record, how will it work? Again, the framework at your rescue. All such conflicts raise an ApplyChangesFailed event for the server sync provider, which you can do by implementing a partial class for your server sync provider. Below is a sample of how to do it.

By default, the changes from the server are overwritten on the client. You can change that logic to say that in the case of ApplyChageFailed, force changes from the client to be over written to the server.

Partial Class LocalDataCache1ServerSyncProvider

    Private Sub LocalDataCache1ServerSyncProvider_ApplyChangeFailed _
            (ByVal sender As Object, _
            ByVal e As Microsoft.Synchronization.Data.ApplyChangeFailedEventArgs) _
            Handles Me.ApplyChangeFailed
        e.Action = Microsoft.Synchronization.Data.ApplyAction.RetryWithForceWrite
    End Sub
End Class

In this case the changes from client are always written to the server. Again this may not be a practical solution as in most case you may want to do some kind of validations before accepting either client or server changes. And the best part is that even that's easy to implement. All you do is take the client changes and server changes and apply your business rule.

Private Sub LocalDataCache1ServerSyncProvider_ApplyChangeFailed _
        (ByVal sender As Object, _
        ByVal e As Microsoft.Synchronization.Data.ApplyChangeFailedEventArgs) _
        Handles Me.ApplyChangeFailed

    Dim clientChanges As DataTable = e.Conflict.ClientChange
    Dim serverChanges As DataTable = e.Conflict.ServerChange

    If (clientChanges.Rows(0)("ModifiedDate") > _
              serverChanges.Rows(0)("ModifiedDate") Then
        e.Action = _
          Microsoft.Synchronization.Data.ApplyAction.RetryWithForceWrite
    End If
End Sub

Here, we are checking the date modified on the server and the date modified on the client, and if the date modified on the client is later, we are forcefully updating the server with the client changes; otherwise, we do nothing. You can apply any business logic here, and in fact, you can use the ApplyingChanges event and modify the data before it is updated. This could be useful in cases where you want to update the values based on some calculations. E.g., in the case of an inventory, you may want to update both the server and the client with the addition of values from the server and client updates.

Points of Interest

This is a real simple example, and in real world, you may have a lot more complex scenario to implement. But, the purpose of this article is to show how easy it is to sync a framework to design occasionally connected Smart Client applications.