Difficult to explain client side synchronization bug RRS feed

  • Question

  • I have been using the Synch Framework for a little over a year now.  In this time I have been able to work through many issues but I am currently stuck. 

    What is occurring is that seemingly randomly tables which are marked as bi-directional for synch fail to transmit their changes to the server.  There are no constraints on the server tables being synched to and additionally the primary key values are all ROWGUID.  In the off chance that there are PK collisions I wrote some code to log all ServerProvider ApplyChangeFailed events.  The log remains empty.

    I began looking into the synch framework code using reflector to try and solve this issue myself.  I found the sql statements used to pull the changes from the client database.  These statements closely resemble the statement provided in the following tool, http://blogs.msdn.com/agujjar/archive/2008/11/22/sync-inspector-tool-inspecting-client-db-state-for-pending-changes.aspx.  While this tool is handy for viewing the "pending changes" it omits the ECSN and LBSN anchors used by the framework so I can not fully trust it's output as 100% accurate.  However, in using this tool I noticed some odd behavior with the client side anchors.  The "Sent Anchor" value seems to increment itself to the largest __sysInsertTxBsn or __sysChangeTxBsn value + 1.  This makes perfect sense to me.  What does not make sense is that once in a while the "Sent Anchor" will reset itself back to 0.  I finally noticed this happening today after the sent anchor had reached 14672 and there was 1 pending change it reset to 23.  My concern which this behavior is what happens to rows which were comitted past 14672 when the sent anchor resets like this?  Seems to me they will be ignored.  

    I saved off a copy of an SDF file where this occurred.  In this database a row inserted on 7/25/09 tramsmitted correctly. This row has a __sysInsert and _sysChange TxBsn value of 1574.  Many more inserts occurred on this client DB after this record was inserted.  By 7/30/09 a series of 6 rows were inserted which did not transmitt correctly.  These rows all seemed to correspond to a reset of the sent anchor values.  One of the rows has a __sysInsert and __sysChange TxBsn value of 35.

    I will continue working on this issue this week and I will post back here if I figure the problem out.  I would be greatly thankful for assistance.  If there are any more obvious ways which my code could be improperly setting the client side anchors please let me know.   
    • Moved by Hengzhe Li Friday, April 22, 2011 2:11 AM (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Monday, August 3, 2009 2:41 PM


All replies

  • Could you take a look at this HotFix?

    Are you using Compact() on your CE database?


    Tuesday, August 4, 2009 4:19 PM
  • Yes, I run Compact() after large volume updates occur.  I will check out the hotfix, thank you for your assistance.  I'll report back here if it solves the issue.
    Tuesday, August 4, 2009 5:05 PM
  • Before applying the hotfix I tested the application to verify that rows were not transmitting after Compact() was run.  I was able to verify Compact() as being the cause of the issue.  After applying the hotfix rows are now transmitting after Compact().  I did quite a bit of searching before posting here and could not find anyone else reporting this issue.  I can't be the only one who needs to compact occassionaly due to performance issues.  I wonder how many developers are missing updates back to the server and not realizing it.  For some applications like mine this causes grave end user safety concerns.  Perhaps a sticky to this thread or an explanation of this problem is in order?  However, I am happy to be back on track with the synch framework and I look forward to the next release which I am sure will make a great product only better.  Thanks again for the help!

    Tuesday, August 4, 2009 6:45 PM