none
Sync Tables sync completed but field values are not in sync

    Question

  • i have some tables where the on premise source rows are updated, the sync completes but the updated fields on the target rows in sql azure are not updated.

    is there a way to check what causes this and prevent this from happening?  also, is there a way to see what are the pending sync transactions for a particular database?

    alternatively, is there a way to force the resync of just particular tables?

    thanks.

    Monday, July 23, 2012 6:19 PM

Answers

  • Is there any special properties on the columns of that table,  like name, collation?  If you could provide the table schema, it would be helpful for us to identify the root cause of it. (You could send it to us via email)

    As a work around, could you try to deprovision and then provision/sync again to see whether this problem is gone? 

    Sunday, July 29, 2012 1:46 PM

All replies

  • does the log show conflicts?

    if your conflict resolution is hub wins and it so happens your client upload was detected as a conflict, it will retain the hub row values.

    AFAIK, there is no way to view the pending transactions.

    same with resynching particular tables, you can't force to resync specific tables.

    if you want, you can do dummy updates on those tables (Update TableX set col1=col1). This should mark them as updated and sync will pick them up on the next sync.

    Tuesday, July 24, 2012 1:32 AM
  • i do have conflict resolution at hub wins but what's the basis of conflict detection?

    will try do do dummy updates and see if they get propagated.

    Tuesday, July 24, 2012 3:35 AM
  • and june, i hope you still remember me :)
    Tuesday, July 24, 2012 3:38 AM
  • of course i do :)

    a conflict is detected if both copies of rows has been updated.

    ex. on-prem updates row1, then at the same time hub updates row 1 as well. when sync tries to upload and apply the on-prem row, it detects that hub copy is updated as well, so it fires a conflict.

    Here's some good reading on the service: Appendix A - Replicating, Distributing, and Synchronizing Data (if you have time, i know youre a busy man :) )

    Tuesday, July 24, 2012 4:03 AM
  • thanks very much for the additional info june.  i did try the dummy update in the source database but the changes did not propagate.  the tracking table entry from the souce was:

    FeatureItemId   2034
    update_scope_local_id  NULL
    scope_update_peer_key  NULL
    scope_update_peer_timestamp  NULL
    local_update_peer_key  0
    local_update_peer_timestamp  0x0000000000462BEB
    create_scope_local_id  NULL
    scope_create_peer_key  NULL
    scope_create_peer_timestamp  NULL
    local_create_peer_key  0
    local_create_peer_timestamp  4588202
    sync_row_is_tombstone  0
    restore_timestamp   NULL
    last_change_datetime  7/24/2012  7:28:57 AM

    Hub's entry was:

    FeatureItemId   2034
    update_scope_local_id  NULL
    scope_update_peer_key  0
    scope_update_peer_timestamp  5191458
    local_update_peer_key  0
    local_update_peer_timestamp  5194046
    create_scope_local_id  14
    scope_create_peer_key  1
    scope_create_peer_timestamp  4588202
    local_create_peer_key  0
    local_create_peer_timestamp  5188901
    sync_row_is_tombstone  0
    last_change_datetime  7/24/2012  2:27:58 PM

    note that source timezone is GMT-8.  is the basis the last_change_datetime for conflict resolution?

    Tuesday, July 24, 2012 2:54 PM
  • nope, afaik, last_change_datetime is not even used.

    how many members do you have on your sync group?

    what does the logs on the portal show in terms of changes applied, failed, etc?

    Wednesday, July 25, 2012 2:41 AM
  • just 2, the on-premise and sql azure hub.

    Portal shows:

    -----------------------

    Sync completed successfully in 554.66 seconds.
     Upload:   2177 changes applied
     Download: 0 changes applied

    For more information, provide tracing id ‘50508a6c-265b-439e-8b2c-eaf7892aa947’ to customer support.

    -----------------------

    But the columns on the hub did not get updated.

    Wednesday, July 25, 2012 3:14 AM
  • strange, it should have reported a problem if it cannot apply the change.

    this may sound obvious, but have you checked the dataset definition if it has the columns you're updating?

    Thursday, July 26, 2012 3:49 AM
  • all columns are in the dataset definition.  can the tracing Id above be used to check what actually happened?
    Thursday, July 26, 2012 6:54 AM
  • if a member of the Data Sync team happen to see this thread :)

    i just pinged someone to see if they can have a look at it.


    Thursday, July 26, 2012 7:39 AM
  • The logs showed the synchronization completed, did you define any filters?
    Thursday, July 26, 2012 3:42 PM
  • no filters.

    Thursday, July 26, 2012 8:25 PM
  • Hey Eugene,

    In this case, are you updating the primary key column value? We know the changes will not be able to sync to the other side under this situation. Data Sync does not support the case of updating primary key column, for now.


    Oliver Yao - MSFT

    Thursday, July 26, 2012 11:55 PM
  • hi oliver,

    no updates on PKs, only on the other columns in the table.

    Friday, July 27, 2012 4:55 PM
  • Is there any special properties on the columns of that table,  like name, collation?  If you could provide the table schema, it would be helpful for us to identify the root cause of it. (You could send it to us via email)

    As a work around, could you try to deprovision and then provision/sync again to see whether this problem is gone? 

    Sunday, July 29, 2012 1:46 PM