none
_selectchanges is always called with sync_min_timestamp=0 RRS feed

  • Question

  • Hi,

    I am using SyncFX2.0 for syncronization in my application which uses SQL CE on client side and SqlServer database on server side.

    There is a table named Instrument in the db. My question is tha even if I have synced server and client, next time I call sync again on this table then also the selectchanges store proc on server is run with sync_min_timestamp as 0. Why does not it search for incremental changes only i.e. since last sync. Is there a way to alter this behavior i.e. to pass the start time?

    exec [Instrument_selectchanges] @sync_min_timestamp=0,@sync_scope_local_id=73,@sync_scope_restore_count=0

    Thanks

    Sumit

    Wednesday, April 7, 2010 9:18 PM

Answers

  • Sumit-

    Even if you synchronize the same client multiple times, you still see zero getting passed in?

    Do you have any conflicts in this scenario?

    Thanks-

    Phil

    • Marked as answer by Sumit J Wednesday, April 21, 2010 7:30 PM
    Friday, April 9, 2010 4:51 PM
    Answerer

All replies

  • when you did the sync, did the change come from server only? client only? or both?

    is it consistently set to 0 even when you had made changes on both replicas already?

    the rows selected by _selectchanges does not necessarily get sent to to the synching party. there is a separate step that goes thru each row retrieved by _selectchanges to verify them against the destination's knowledge if the changes really need to be sent.

    Thursday, April 8, 2010 11:43 AM
    Moderator
  • I have set the direction of sync for this sync group as download only i.e. only changes from server will be fetch to clients. And it is consistently set to 0 even if I run the sync several times.

    You are right that not all the rows selected by _selectchanges procedure are sent to the client, but I am still wondering why are all the rows selected at the first place. Although this is not affecting the correctness of the behavior, but its increasing the time to run the whole sync.

    Any thoughts on why this may be happening?

     

    Thanks

    Sumit

    Thursday, April 8, 2010 1:37 PM
  • Sumit-

    Even if you synchronize the same client multiple times, you still see zero getting passed in?

    Do you have any conflicts in this scenario?

    Thanks-

    Phil

    • Marked as answer by Sumit J Wednesday, April 21, 2010 7:30 PM
    Friday, April 9, 2010 4:51 PM
    Answerer
  • Sumit-

    Could you enable SyncTracer to get more detailed output for the synchronization and share the output?  This will help show why zero is getting passed to the procedure for subsequent downloads.

    For details on how to enable tracing, please see:

    http://msdn.microsoft.com/en-us/library/cc807160.aspx

    Level 4 will give the most detailed output. 

    Thanks-

    Phil

    Wednesday, April 21, 2010 7:17 PM
    Answerer
  • Hi Phil,

     

    I tried this again and this time I found that there were few conflicts in syncing this syncgroup. There is a seperate problem why these conflicts were occuring. Actually these conflicts were errors related to some constraint on table being violated in the data picked by _selectchanges stored proc.

    Anyway, after resolving these errors when I synced again, the min_timestamp was not 0 rather it had some non zero value, which I wanted. So it seems to be working fine now.

    Thanks a lot for giving the right hint!!

     

    - Sumit

    Wednesday, April 21, 2010 7:30 PM
  • Faced the same issue (@Sync_min_Timestamp always 0). Logged the error messages from the DBApplyChangeFailedEventArgs by handling the provider's ApplyChangeFailed event and found there were null constraint violations.

    Thanks for the info. :)

    Thursday, September 2, 2010 10:08 PM