What does this error mean? Cannot enumerate changes at DbServerSyncProvider RRS feed

  • Question

  • I occassionally get this error message when performing a sync.  I do not see any references to it when doing an Internet search.  What does it mean?

    Cannot enumerate changes at DbServerSyncProvider for table 'MyTableName' in synchronization group 'MyTableNameSyncTableSyncGroup'. 

    I am using SyncFramework 2.1 with SQL Server 2008 using change tracking to sync down to a SQL CE 3.5 database.  This only happens on the tables with change tracking enabled, and seems to only crop up after we have done an update of our database, but becaue it only happens after some updates, it has been difficult to determine what the exact origin of the issue is.

    Wednesday, August 3, 2011 12:57 PM

All replies

  • have a look at the inner exception.

    have you changed table schemas?  did you use the Local Database Cache to configurate the synchronization?

    Wednesday, August 3, 2011 1:08 PM
  • Despite the error messge, there actually is no inner exception.  My table has not changed schema.  How do I know if I used the Local Database Cache?  What is that referring to?  I double clicked on the .sync file and used the "Configure Data Synchronization" dialog to configure syncronization.

    Wednesday, August 3, 2011 1:17 PM
  • hard to tell what's causing it then. it could be caused by command timing out, change tracking data being cleaned up, etc...

    have you tried enabling Sync Framework tracing?

    if you have a .sync file, that's generated by the wizard.

    Wednesday, August 3, 2011 1:42 PM
  • Verbose, but no errors are logged, even though the SyncAgent.Synchronize method is definitely throwing an exception. 

    The only thing I can discern from the trace log is that all of the tables that work properly have SentAnchor: null and ReceivedAnchor: null.  The table that is failing has SentAnchor: null and ReceivedAnchor: 100.  Do you know what the significance of "Read ReceivedAnchor value: 100" is?

    Wednesday, August 3, 2011 2:56 PM
  • the receivedanchor is just to record the anchor from the last sync.

    what's the sync direction for your sync? i wonder why your other tables have null anchors. is it still null on subsequent syncs? can you check the anchor tables on your client if they have values.

    Wednesday, August 3, 2011 3:02 PM
  • My syncs are all download only. I never push anything back up to the server. All of the syncs that are set to "Entire Table Each Time" are the ones with null ReceivedAnchor. The only tables that have ReceivedAnchor 100 are the few that use "New and incremental changes". The __syncArticles table has a row for each of the "New and incremental changes" tables, but not the others. The ReceivedAnchor column reads <Binary data> for each, so there is a value, but I cannot see what the value is.
    Wednesday, August 3, 2011 3:13 PM
  • Is there any chance this is being caused by the change tracking retention period with auto cleanup?  I currently have this set to 2 days on my SQL Server database.  Once two days have passed, would any client trying to re-sync get an error?  What are the recommended settings for change tracking when used in conjunction with the sync framework.  I would have thought that if syncing more than 2 days out, the client might simply get more information than needed, not an exception.
    Wednesday, August 3, 2011 3:33 PM
  • the client will get an exception when change tracking metadata is cleaned up. if you look at the sync generated code in your app, you will see that message embedded in the selectincremental queries
    Wednesday, August 3, 2011 11:46 PM
  • I expanded the change tracking retention period, but I still got the error this morning after a system update.  Are there any more ideas out there as to what specifically generates this error?


    Cannot enumerate changes at DbServerSyncProvider for table 'MyTableName' in synchronization group 'MyTableNameSyncTableSyncGroup'.

    Thursday, August 4, 2011 4:53 PM
  • try running Sql Profiler and see if it even fires a query to the database and if it does, try to capture the query and run it yourself to see if its running ok.

    check permissions, schema (is it under dbo or some other schema), look at the generated code and see the select statement yourself and compare with the table structure.

    Friday, August 5, 2011 12:55 AM