Determine how many records changed exactly when using SnapShot Microsoft Sync RRS feed

  • Question

  • Hi

    I want to determine how many records / Which records  changed exactly when using SnapShot

    sync direction using Microsoft Sync. When we use snapshot all the records would be downloaded,

    but not all of them would have changed at the client side. 

    Saturday, March 20, 2010 2:05 PM

All replies

  • Hi  JUNE,

    How can I retrieve last sent anchor. Where is the time stamp stored for table rows.

    Its because I dont last have modified date in have used SNAPShot.


    Sunday, March 21, 2010 8:23 AM
  • JUNE,

    According to this,

    retrieving the last received anchor and fire off a query to get the row count of all rows whose timestamp is greater than the last received anchor

    Will there be any timestamp / (where is that timestamp stored ) for the actual records thats are being Synced. I am sure I will be able to get the Last  Received Anchor.


    Sunday, March 21, 2010 2:26 PM
  • I tried to run this query using  both visual studio and through .NET code. It says table does not exist.
    Monday, March 22, 2010 5:11 AM
  • Hi Harsha,

    Apologies for the confusion, turns out i was working with a copy of an SDF i have previously configured for bidirectional sync and I thought i was working with a snapshot copy and I thought the behaviour would be the same with the collaboration providers GenerateSnapshot method.

    In snapshots for offline providers, there is no change tracking since the table is refreshed everytime you sync, thus the change tracking objects are not there.

    If you want to track the changes, you can change syncdirection to DownloadOnly. If you used the Local Database Cache designer, it's not enough that you change the syncdirection since the SelectIncremental queries are not tracking changes. So you'll have choose New and Incremental Changes in designer.

    I've deleted my previous post to your query so as not to confuse others reading the thread.

    Again, sorry for the confusion.

    Monday, March 22, 2010 5:57 AM