Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Synching client database is not picking up server database updated rows, why? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have gone through the thread "Synching client database is not picking up server database new rows, why?" I have almost the similar issue, which @sync_min_timestamp is bigger than [side].[local_update_peer_timestamp]. The changes I made on the server do not come to the client. But the changes I made on the client dataabse will sync to the server. Beside re-prevision the database, is there any way I can reduce the value of @sync_min_timestamp?

    By the way, where is the value of @sync_min_timestamp saved? It is in this cloumn: [scope_info].[scope_sync_knowledge], correct? And each scope of a client database will have a corresponding value of @sync_min_timestamp, correct? This really helps me to understand how the sync framework works?

    Please advise!

    Thanks!

    JZ  



    • Edited by jz2012 Wednesday, June 5, 2013 11:36 PM
    Wednesday, June 5, 2013 10:27 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    1 - when you restore a database that's been provisioned for sync, you must call PerformPostRestoreFixup before you sync it for the first time.

    sync min timestamp is derived from the sync knowledge and that is stored in scope_info table in all participating databases.

    • Marked as answer by jz2012 Friday, June 7, 2013 12:37 PM
    Thursday, June 6, 2013 1:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    if by debugging you mean actually synching it, yes it will cause a problem if the original database continuous to sync and you didnt do a post restore fixup.

    • Marked as answer by jz2012 Friday, June 7, 2013 12:36 PM
    Friday, June 7, 2013 12:58 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    yes, there will be an extra replica key map entry for it and sync knowledge. the size of its entry in the sync knowledge depends on the number of changes you make and if it results to fragmentation (e.g, lots of deletes). if its just a couple of inserts, updates, deletes to test the sync, wont blow the sync knowledge that much.
    • Marked as answer by jz2012 Friday, June 7, 2013 5:04 PM
    Friday, June 7, 2013 3:18 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    some things for you to look at:

    1. are any of the the databases a restored copy?

    2. when you do your update, does the corresponding row in the tracking table get updated?

    3. if #2 is true, run Sync Fx tracing to see if the changes are being picked up and to figure out if its having issues applying the change...

    Thursday, June 6, 2013 12:55 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    In response your questions, (1), Yes; (2), Yes

    I turn on the trace. The problem is that the passing value of @sync_min_timestamp Value: 519902 is always greater than [side].[local_update_peer_timestamp] (0x000000000006DDB7 which is 449975)

    Executing Command: [Membership_selectchanges]
    Parameter: @sync_min_timestamp Value: 519902
    Parameter: @sync_scope_local_id Value: 64
    Parameter: @sync_scope_restore_count Value: 0
    Parameter: @sync_update_peer_key Value: 17
    Parameter: @ScopeName Len: 9 Value: DataTable

    By the way, where is the value of  @sync_min_timestamp Value: 519902 stored? In the client database or server database?

    Please advise!

    Thanks! I appreciate your help!!!!

    JZ


    • Edited by jz2012 Thursday, June 6, 2013 1:23 PM
    Thursday, June 6, 2013 1:18 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    1 - when you restore a database that's been provisioned for sync, you must call PerformPostRestoreFixup before you sync it for the first time.

    sync min timestamp is derived from the sync knowledge and that is stored in scope_info table in all participating databases.

    • Marked as answer by jz2012 Friday, June 7, 2013 12:37 PM
    Thursday, June 6, 2013 1:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks a lot!

    I have read your previous posts which you have clarified the restore process already. Here is one question I have.

    If one client computer has a issue with the sync, can I have a copy of his database and then debug in my computer? Will this cause problem?

    JZ

    Thursday, June 6, 2013 2:10 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    if by debugging you mean actually synching it, yes it will cause a problem if the original database continuous to sync and you didnt do a post restore fixup.

    • Marked as answer by jz2012 Friday, June 7, 2013 12:36 PM
    Friday, June 7, 2013 12:58 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks very much! I appreciate your help!

    I am wondering if I can have one more question here:

    After doing a post restore fixup and then start sync, the new scope Id will participate in the sync process. Since it is only for testing purpose, we will not user this scope id any more. If we do this frequently, does this will cause a larger size of knowledge?

    JZ


    • Edited by jz2012 Friday, June 7, 2013 12:43 PM
    Friday, June 7, 2013 12:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    yes, there will be an extra replica key map entry for it and sync knowledge. the size of its entry in the sync knowledge depends on the number of changes you make and if it results to fragmentation (e.g, lots of deletes). if its just a couple of inserts, updates, deletes to test the sync, wont blow the sync knowledge that much.
    • Marked as answer by jz2012 Friday, June 7, 2013 5:04 PM
    Friday, June 7, 2013 3:18 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks very much! I appreciate your help!

    Have a great weekend!

    Friday, June 7, 2013 5:05 PM