locked
ProcessChangeBatch is eating SqlExceptions RRS feed

  • Question

  • I've spent a couple of hours tracking this down. I was getting upload failures, but none of my conflict resolution code was firing. I turned on breaking on First Chance Exceptions and found that ProcessChangeBatch is eating SqlExceptions. The only way I can figure out how to troubleshoot the exceptions is to run in the debugger with this turned on and read each exception manually. No I seem to have a pretty large mess on my hands as every client is starting to have this issue. Can anyone tell me why it might be eating SQL errors or how I could programmatically go about seeing and dealing with the errors?

    Thanks in advance,

    Mike

    Monday, November 8, 2010 8:58 PM

Answers

  • what's you're consuming/using in your client application is a proxy to the sync provider that's in the WCF service.

     

    I'm pretty sure the FK violation is raised in the ApplyChangesFailed on the WCF service side. It's not eaten by Sync Fx but is actually captured a ConflictType.ErrorsOccurred on the remote provider ApplyChangeFailed event.

     

    Add the event handler in the remote provider and either handle it on the WCF service side or have the WCF service propagate it back to the client application either as a fault or as a callback.

    • Marked as answer by Mike E Yeager Tuesday, November 16, 2010 7:58 PM
    Thursday, November 11, 2010 2:50 AM

All replies

  • what errors are you getting? are you checking for ConflictType.ErrorsOccurred  in the ApplyChangeFailed? have you tried enabling Sync Fx tracing?
    Tuesday, November 9, 2010 4:16 PM
  • In this case, the error was caused by someone adding an FK constraint to a table. The insert would fail because of the constraint, but the exception was being eaten.

    Because I'm using WCF, I'm implementing my own SqlWebSyncService which inherits from ISqlSyncContract on the server side. There is no ApplyChangesFailed event to subscribe to. All of the documentation tells me to subscribe to the ItemConstraint event on a SyncCallbacks object passed into ProcessChangeBatch. I did that, but it never fires. I also found and subscribed to ItemConflicting event which doesn't seem to be in any examples anywhere, but that doesn't fire either. I suppose I could subscribe to all of the events and see if any of them fire...

    I have not even heard of Sync Fx tracing. I'm going to Bing that now and see what that tells me. So far, this whole framework seems to contain a lot of "magic". Most of the time, the magic works and all is good, but when it doesn't... Something as basic as finding that a remote db is out of sync and doing a ground-up re-sync has been a painstaking and mysterious process that usually comes down to - create a new remote db and manually re-insert any records from the old remote db that didn't make it. Ick. Maybe this tracing mechanism will take some of the magic out of it!

    Wednesday, November 10, 2010 7:08 PM
  • what's you're consuming/using in your client application is a proxy to the sync provider that's in the WCF service.

     

    I'm pretty sure the FK violation is raised in the ApplyChangesFailed on the WCF service side. It's not eaten by Sync Fx but is actually captured a ConflictType.ErrorsOccurred on the remote provider ApplyChangeFailed event.

     

    Add the event handler in the remote provider and either handle it on the WCF service side or have the WCF service propagate it back to the client application either as a fault or as a callback.

    • Marked as answer by Mike E Yeager Tuesday, November 16, 2010 7:58 PM
    Thursday, November 11, 2010 2:50 AM
  • I see that you are right, I did figure out how to subscribe to this event on the service side and log it. I'll be testing it today to see if it does in fact capture the exception. I am using the sample code from the WebSharingAppDemo and it doesn't have any code for this. Thanks for the push in the right direction. I'm starting to figure this out. :-)
    Mike Yeager
    Thursday, November 11, 2010 5:09 PM
  • I have the same problem too, can you solve this? Thank you
    Monday, February 21, 2011 8:16 PM
  • The other thing to always try and do is make sure that 2 tier scenario works fine. This helps to make sure there is no other problem in the logic of your code for 2-tier.
    This posting is provided AS IS with no warranties, and confers no rights
    Monday, February 21, 2011 8:37 PM
  • It was in fact making the call-back, but if you don't subscribe to the event, then you never know there was a problem and it appears to eat the exception. Not very intuitive default behavior, but that's how to fix it.
    Mike Yeager
    Monday, February 21, 2011 8:56 PM