If you had time to browse the documentation for Synchronization Services for ADO.NET, you might have seen a class called SyncAnchor. You don’t deal with it directly and none of the demos in my blog interact with it directly except the server command called GetNewAnchor which returns a new timestamp value. However, as you build up your sync knowledge you will appreciate what this type can do for you. Hmm, have you noticed that too? Truly powerful types appear low profile from far!
The anchor in sync services is that marker that the client stores after every successful session in order to use it next time to tell the server where it left off in the last sync session. The server provider generates a new one for the new sync session. The changes between the old and the new anchors are enumerated and sent to the client. In simple scenarios, sync anchor will be something like timestamp, datetime or any monotonically increasing number that your server store maintains. However, it could carry much more than a number. You could overload the anchor to hold the date and time of when the sync took place; this is useful for detecting rouge client who did not sync for very long time that the server has lost track of some old changes – tombstones for example – thus synchronizing with such client could result in data loss or non convergence. In addition, you could also store a token for changes that the server could not pass on to the client in the current sync and would like to try aging in the next sync. The possibilities are endless.
One thing you need to be aware of is that the anchor value is serialized by the server provider prior to sending them to the client and desterilized before they are used at the server. Your application needs to follow this protocol to plug smoothly into the sync runtime and leverage the power of the sync anchor.
Tip: I had very interesting discussions in the forum, make sure to check it out