locked
SQL Server Change Tracking has cleaned up tracking information for table. What does this mean? RRS feed

  • Question

  • Hu Guys,
    Little problem with change tracking here.
    Basically I have it set up via the local database cache wizard and have tweaked the code to support bidirectional changes for a few of the tables.
    My issue now (and its kinda come out of no where) is that syncing is working one one deployment of the app, but not another. In fact I can zip up my project, move it to my other PC, unzip and F5 to run it and the syncing fails.
    The inner exception is as follows:
    SQL Server Change Tracking has cleaned up tracking information for table 'dbo.tblRegion'. To recover from this error, the client must reinitialize its local database and try again

    Now Im not totally sure what this means. As I understand MS SQL Server 2008 keeps a track of changes and the client is stored via an ID. Could this value be causing the problems somehow? If so how do I set it? Im might be going in totally the wrong direction here.

    PS  - THis is using the exact same project on two machines - same local database file and everything. Works on one and not the other. :(

    Thanks,

    - UPDATED title to reflect the fact that it no longer effects only one client - rebuilding on the working client broke it! see post below.
    • Edited by Warpkid Monday, May 18, 2009 10:37 PM
    • Moved by Max Wang_1983 Thursday, April 21, 2011 11:25 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Monday, May 18, 2009 4:17 PM

Answers

  • There is a ton of info on this error on MSDN.  It simply means that your database server has run change tracking cleanup since your client last synchronized thereby causing a situation where your client's database may be missing rows or be otherwise inaccurate.  It detected this because...
    MIN_VALID_VERSION (the current version on the server) is greater than your client's last pulled version.  This means, the last version on the server which is valid after cleanup is from a point AFTER your client last synched.  You can solve this in a couple ways...

    Increase the cleanup window for change tracking on the server. By default it is something like only three days I think.
    Ensure that you are not dropping or altering tables on your server and deleting change tracking info.
    Detect this specific error message on the client and when it happens, drop the named table and recreate it using snapshot sync.
    Make sure your client's synch regularly (or at least within your cleanup window) if this is possible.
    Monday, June 1, 2009 6:18 PM

All replies

  • Anyone got any ideas? This is kinda critical and google is turning up nothing but dead ends! :-(

    A little more info.
    I rebuilt the application on the machine on which it WAS working, and it is now getting the same error.
    Very strange!

    Monday, May 18, 2009 10:15 PM
  • Ok, I have a theory. Could someone please verify this is the case?

    As far as I can tell the sync session checks to see if the table that is is going to sync to has been cleaned up, and I am assuming this means the tracking information has been removed. It does this through IF CHANGE_TRACKING_MIN_VALID_VERSION (object_id (@sync_table_name)) > @sync_last_received_anchor

    So bearing in mind that VS stores its SQL Server CE database in the root, and then copies it to the BIN folder during first build, could the problem be that if you rebuild the app that the CE database is effectivly getting reset and so losing its client side change tracking information?

    The only option when this happens is to let the client sync provider rebuilld the database and so pull all the data again and rebuild its change tracking information?

    Im sorry if this seems like a stupid post - Im not the sharpest tool in the shed and Im new to sync services!

    If this is the case then I can relax and I know this problem wont occur when we deploy the system as its an issue with VS keeping two copies of the local SQL CE Database.
    Monday, May 18, 2009 11:34 PM
  • There is a ton of info on this error on MSDN.  It simply means that your database server has run change tracking cleanup since your client last synchronized thereby causing a situation where your client's database may be missing rows or be otherwise inaccurate.  It detected this because...
    MIN_VALID_VERSION (the current version on the server) is greater than your client's last pulled version.  This means, the last version on the server which is valid after cleanup is from a point AFTER your client last synched.  You can solve this in a couple ways...

    Increase the cleanup window for change tracking on the server. By default it is something like only three days I think.
    Ensure that you are not dropping or altering tables on your server and deleting change tracking info.
    Detect this specific error message on the client and when it happens, drop the named table and recreate it using snapshot sync.
    Make sure your client's synch regularly (or at least within your cleanup window) if this is possible.
    Monday, June 1, 2009 6:18 PM
  • Hi There,
    Thanks for your reply.
    I have continued to look into the issue and yea, I now understand how it occurrs and how it would be preveted. (MSDN did help ;-))
    I understand that if this error is thrown on the client that I'll have allow them to cut their losses and redownload the table in snapshot mode. I presume this resets the change tracking anchors, otherwise the error will be raised the next time a bidirectional sync is tried?

    Is there a recommended method for picking up the erroring tables, dropping them and redownloadin? I was hoping that the syncAgent would provide a simple means of just allowing you to tell it to reinitialise the client database. :)

    I'll shall look into implimenting your suggested functionallity and seeing if I can get it to work. Thanks for your help.

    Tuesday, June 2, 2009 10:47 AM
  • You would think it would provide a method of reinitializing the database and the tables, seeing as it knows what they are and has decided you have to reinitialize.

    Obviously that capability would make this framework seem somewhat complete, so it is not included.
    Tuesday, August 25, 2009 6:05 PM
  • Another way to reinitialize the client database is to reset the anchors on the tables.  The following post describes how to reset the anchors which will effectively "reinitialize" the client database without having to drop the tables or delete the SDF.

    http://social.microsoft.com/Forums/en-US/uklaunch2007ado.net/thread/0e2dd016-5d14-4cf9-aebc-93b762b42ec7

    Tuesday, September 15, 2009 4:12 PM