I originally authored the offline application line of samples to show off the different features of Sync Services. My main goal back then was to provide you with a quick start guide such that you can get into sync quickly. The series of demos has grown to up to eight demos, so as the rate of positive feedback that I’ve been receiving from you and even internally inside the company. Well, for that I thank you!

Now, with the release of our new DbPeerSyncProvider which is included in CTP1 of Microsoft Sync Framework, a new series of demos is also released with it. This time it is part of the SDK. On my machine, the samples are located at: C:\Program Files\Microsoft Sync Framework\v1.0\Runtime\ADO.NET\V2.0\Samples\

I called this new line of demos “Sharing Application” to emphasize the key feature of the peer provider which enables different nodes to share and collaborate on a common data set without the need for central authority. Not to say that having a central database is discouraged, it is just not required.

The SDK ships with five different flavors of the sharing application sample. They share the same user interface and act against the same database schema of orders and order_details tables. If you have tried the offline application demos, you will feel right at home with this new set of samples. I want to give you an overview of each sample and what features of the provider it shows off. But before going there, let’s check out the common user interface for these samples

The first thing to pay attention to in the main form as shown above is the three peers (peer1, peer2, peer3) settings in multiple places. On the top right you configure the machine name where the database is located for each peer (I have all three databases on one machine). On the bottom left, you direct the follow of synchronization through to and from boxes. The UI won’t allow you to select to sync from a given peer to itself. The three conflict generation buttons on the left of the Synchronize button are specific to conflict sample. Other samples might introduce new buttons.

In building multi-master sync application, three nodes are required to exercise almost all possible scenarios and that’s why you see three peers. You can extend the demo and add as many peers as you want; but as far as the demo goes, three peers should suffice.

In the setup directory with every sample there is a bunch of .sql files that you should use to create the peer databases along with all necessary stored procedures and triggers. The peer provider requires snapshot isolation transaction while enumerating changes, which means that you need any flavor of SQL Server 2005. SQL Server 2005 Express should work just fine.

So now you are eager to give it a try, the question is where to start. Let me give you a quick overview for each sample, ordered by complexity, starting with the simplest of course:

1. SharingAppDemo – Coupled Tracking
   Following the most common model used in the offline application demos, here too you start with your base table and add necessary tracking columns to it. For recording deletes, you create a tombstone table for that.
    
2. SharingAppDemo – Decoupled Tracking
   You soon realize, after trying the first demo, that tracking metadata for p2p sync is rather demanding and adds many columns to the base table that makes you uncomfortable. Well, I’ve gotten the same feeling myself and this demo shows you how to leave your base table schema intact and move all tracking metadata to a side table called “tracking table”. The rest of the demos are built on top of the decoupled tracking technique so you should give a little bit of time to this demo.
    
3. SharingAppDemo – Tombstone Cleanup
   In the peer to peer sync world metadata cleanup is not taken lightly and the peer provider has a special logic for handling the cleanup for you. You just need to call the right method on the provider interface when you need to cleanup the metadata stored for deleted rows. This demo shows you how to do that.
    
4. SharingAppDemo -  Column Mapping
   In many situations the table schema is different on each node. Despite the diversion in columns names, columns data types are identical which make sync possible. If all nodes decide to agree on a global schema definition, they all could sync without problems. This demo shows you the idea of global schema. It does not use different schema on each node but it maps column name on each node to a global schema name and shows you how that works. If you don’t have this kind of scenario, you could skip this demo.
    
5. SharingAppDemo – Conflicts
   It is always fun to show conflict detection and resolution logic. It is my favorite anyways. Once you get comfortable with the peer provider normal sync logic, your treat is to check out how conflicts are handled in peer to peer environment. This demo shows you different types of conflicts and different types of conflict resolution including the ability to retry applying the conflicting row in the next sync.

I am very much exited about this new sharing demo series. I think you going to like it too. As always, your comments are welcomed and you feedback is much appreciated.

Update: Just to let you know, I left Microsoft to start a new company, Raveable Hotel Reviews. See examples: Romantic Hotels in NYC, Best Hotels in Seattle, Top 10 Hotels in Myrtle Beach, Kid Friendly Hotels in Chicago, Hotels with in-room jacuzziand Best Hotels in Miami. Your feedback is welcome on twitter.com/raveable, raveable blog.

I am not actively blogging about Sync Technologies. Please see Sync Team Blog for more updated content.