none
Sync Validation RRS feed

  • Question

  • I asked this as a follow up question that was solved so probably wasn't getting many views so I'll start a new thread with it. We are using Sync Framework 2.1 to Azure storage. Our data is sensitive so we would like to delete it on our local clients after upload to Azure. We want to be sure that the upload was successful before deleting. Not knowing the protocol for error correction and resend used by Sync Framework we would like to know if after sync there are no errors reported can we be assured that the data got there or should we do a secondary validation before deleting the client data.  Compromising a set of client data would be bad but losing it would be worse.


    Donald Hofferber

    Thursday, March 21, 2013 11:23 PM

Answers

  • you should subscribe to the ApplyChangeFailed event of the remote provider (the Azure SQL in your case) to catch any error or conflicts encountered during the upload. 

    or you can also just rely on the SyncStatistics returned by the SyncOrchestrator.

    Or if you really want to be sure, you can do hash counts between client and server and compare them.

    on another note, how do you plan to do the delete on the client? delete the database or delete the rows?

    if you delete the rows, that will get recorded as changes that will be picked up on next sync and applied as delete on the server side.

    • Marked as answer by DDHSolutions Thursday, March 21, 2013 11:58 PM
    Thursday, March 21, 2013 11:53 PM
    Moderator

All replies

  • you should subscribe to the ApplyChangeFailed event of the remote provider (the Azure SQL in your case) to catch any error or conflicts encountered during the upload. 

    or you can also just rely on the SyncStatistics returned by the SyncOrchestrator.

    Or if you really want to be sure, you can do hash counts between client and server and compare them.

    on another note, how do you plan to do the delete on the client? delete the database or delete the rows?

    if you delete the rows, that will get recorded as changes that will be picked up on next sync and applied as delete on the server side.

    • Marked as answer by DDHSolutions Thursday, March 21, 2013 11:58 PM
    Thursday, March 21, 2013 11:53 PM
    Moderator
  • OMG.  Do you ever feel really really stupid.  I do now!  We'll have to think about this a bit more.  If we delete the rows and then deprovision and reprovision the client db would the deletes be ignored on Azure?  Any other ideas?

    Donald Hofferber

    Friday, March 22, 2013 12:02 AM
  • deprovision -> delete -> reprovision will be much faster than deleting->deprovision->reprovision as the latter would cause the change tracking triggers to record the deletes.

    are you using identity columns for PKs ?

    Friday, March 22, 2013 12:52 AM
    Moderator
  • I'm testing the deprovision -> delete -> reprovision but another question came up.  When we deploy we will be using auto migrations with Entity Framework.  Do you know if we should deprovision-> migrate -> reprovision or something else?

    Donald Hofferber

    Friday, March 22, 2013 3:46 PM
  • sync fx will not pick schema changes...and the current api doesn't allow you to modify an existing scope, so you will have to deprovision/reprovision.

    or if you're up to it, i did some blog post on how to go about modifying scope definitions. there's another one here as well in the forum...just search for schema change... 

    Friday, March 22, 2013 3:50 PM
    Moderator
  • On the question of what to test to assure sync before deleting on client.  Our client tablets are for data gathering at multiple locations.  All data gathered by a client are unique to that client so we should never see a client row conflict.  We are using GUIDs as our PKs which are identity columns so we should never see a duplicate key conflict.  Under these conditions, it seems that we can get away with SyncStatistics returned by the SyncOrchestrator for validation.  Thoughts?  Perhaps we should still subscribe to ApplyChangeFailed event to further assure validation but I don't see a condition that might trigger the event?  Not sure what row error is on that event.

    Donald Hofferber

    Saturday, March 23, 2013 9:59 PM
  • might be worth still subscribing to ApplyChangeFailed event just in case something pops up. if nothing pops up, no harm done. it doesn't get called.

    other option is to compare the row counts in ChangesSelected event on local provider with ChangesApplied on remote or sync statistics.

    Monday, March 25, 2013 1:07 PM
    Moderator
  • I like the idea of comparing row counts.  I read your blog on "Manipulating the change dataset...".  I don't see any simple way to get the counts other than looping through all of the tables and add up rows inserted, updated or deleted in each.  Do you know of a simpler way to get the counts to compare?

    Donald Hofferber

    Monday, March 25, 2013 5:26 PM
  • none that i know of if you want a breakdown of inserts/updates/deletes.
    Wednesday, March 27, 2013 12:59 AM
    Moderator