locked
Overwriting Anchor to resubmit a batch of changes RRS feed

  • Question

  • Hi

    I'm new to MSF having inherited a system that using MSF to sync data from clients to a central server.

    What I've found is that very occassionaly a record or two isn't uploaded correctly.

    We have around 50 clients uploading (single direction) to a central database every 15 minutes.

    There is an event handler at both the client and server end.  The server end isn't reporting any errors in these circumstances, although it does seem to kick in when erroneous data is uploaded.

    On the client side, there is anApplyChangeFailed handler (as below) which doesn't report errors

    So there is a

        Dim ClientProvider As New SqlExpressClientSyncProvider

        ClientProvider.ApplyChangeFailed, AddressOf ApplyChangeFailed

    and then

        Private Sub ApplyChangeFailed(ByVal sender As Object, ByVal e As ApplyChangeFailedEventArgs)
            If e.Conflict.ConflictType = ConflictType.ClientUpdateServerUpdate Then
                e.Action = ApplyAction.RetryWithForceWrite

            ElseIf e.Conflict.ConflictType = ConflictType.ClientDeleteServerUpdate Then
                e.Action = ApplyAction.RetryWithForceWrite
            ElseIf e.Conflict.ConflictType = ConflictType.ClientInsertServerInsert Then
                e.Action = ApplyAction.RetryWithForceWrite
            ElseIf e.Conflict.ConflictType = ConflictType.ClientUpdateServerDelete Then
                e.Action = ApplyAction.RetryWithForceWrite
            End If

            If Not e.Error Is Nothing Then
                Dim Ex = DirectCast(e.Error, Exception)
                WriteToErrorLog(Ex, "ApplyChangeFailed")
            End If
        End Sub

    but this doesn't seem to log any errors, but

        stats = Agent.Synchronize()

    does report 1 or more Stats.UploadChangesFailed.

    So, 2 questions

    1. Any ideas why the Synchronize call doesn't trigger the ApplyChangeFailed (which it might, but would need e.error to be nothing not to be logged so I'd get no error details anyway)
    2. Being bullish, can you see any problem with taking a copy of anchor, and in the case of any error, copying it back so (in my little brain anyway) on the next sync it would 'retry' from the start of the previous (errored) sync.

    On question 2, if there is a fundamental data problem with the failed rows it will still fail.  But I've tried deleting anchor and doing a full resync on databases that have recorded error (which isn't practical in the real world) and the erroneous rows were then successfully uploaded, showing there was nothing fundamentally wrong with them.

    I'm sure the question will upset purists but I've very limited time to address this (as it always the way), so if a lump-hammer will work I'm all for it :-)

    Many thanks

    Mike


     

    Sunday, October 30, 2011 1:07 PM

All replies

  • the ApplyChangeFailed  event on the client provider applies to Downloads being applied on the client side. In an upload scenario, you should subscribe to the ApplyChangeFailed event of the remote provider.
    Sunday, October 30, 2011 1:40 PM
  • Hi June

    Yeah, we've got that at both ends that's not firing an error (in this instance).

    Regards

    Mike

     

    Monday, October 31, 2011 9:43 AM
  • have you tried putting a breakpoint on the remote provider's ApplyChangeFailed event?

    for the missing records, have you tried manually inserting/updating directly against the database to see if it goes thru or fires some errors?

    when troubleshooting this scenario, i would normally look at the characteristics of the failing rows that differentiates them from the successful rows.

    Tuesday, November 1, 2011 1:20 AM
  • Hi June.

    Thanks for your replies :-)

    I log to a text file and to SQL every time the ApplyChangeFailed event fires and this appears to log if I force an error by e.g. oversizing a VARCHAR field on the client side so getting a String or Binary Data Would be Truncated error.

    Also, if I just delete Anchor and re-sync everything uploads.

    Have you got any thoughts about saving Anchor, and if I get an upload error reported on the client, just restoring them so it effectively retries on next sync?

    It's not pretty but!

    Many thanks

    Mike

     

     

     

     

    Tuesday, November 1, 2011 2:04 PM
  • if you reset the anchor, you will have to address conflicts that may arise for changes that has already been applied or having to download again the same rows that was previously downloaded already.

    i suggest, you log the conflicting errors, have it fixed then sync again.

    one thing im curious about your scenario is why deleting the anchor and re-synching works. if there's a problem in a row, resetting anchors should have no impact on it.

    can you try enabling sync framework in verbose mode and see what else its showing?

    Wednesday, November 2, 2011 12:57 AM
  • Hi June

    Resetting anchor completely (i.e. delete from anchor) deos re-send everything so is no use for real-world use, but does 'fix' the data.

    "one thing im curious about your scenario is why deleting the anchor and re-synching works".  I'm curious about this as well.  It would appear that there isn't anything wrong with the row, otherwise, as you said, it would fail again when it re-sent, but it doesn't.

    The client side indicates an error, but the server side seems oblivious to this. 

    Thanks for the tip on verbose mode (I'm pretty new to MSF so didn't know there was one :-S ).  I'll give that a try.

    Many thanks again.

    Mike

     

     

    Wednesday, November 2, 2011 9:09 AM