Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Sync Starts But Never Ends over WCF HTTPS RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    Here's all I know, if I can get a database from the client I can begin troubleshooting:
    • Sync starts and never finishes
    • It is happening for multiple users
    • Sync never seems to "time out" so I'm assuming the WCF service is keeping constant communications with the app
    • Using Sync Service 1.0
    Any ideas on how to troubleshoot this on my end?  While it's probably bad design I removed relationships on all tables as I was using the designer generated file for syncing and it was syncing my tables in the wrong order. 

    The weird thing is that everything was working fine and then all of the sudden almost randomly this started happening to a lot of people.  Could it be because I have too many people syncing at once?  Please let me know if you have any ideas where I can even begin to start troubleshooting. 

    Travich
    Friday, March 5, 2010 4:28 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    As you know we've talked before -- how can I get rid of what's stored in the conflict table when I continue?  That info is what caused that memory leak for me.
    Travich
    Saturday, March 6, 2010 5:30 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    that will be under SyncContext.GroupProgress.TablesProgress.

    Here;s a code snippet on how i go about clearing it.

     //assuming the conflicts had been handled on the service side
 // we don't need to download them anymore, so let's clear the conflict collection
 foreach (SyncTableProgress syncTableProgress in syncContext.GroupProgress.TablesProgress)
 {
      syncTableProgress.Conflicts.Clear();
 }
    Monday, March 8, 2010 3:13 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    hi travich,

    you can run SQL Profiler to check if there are any Sync related SQL executed in your SQL Server.

    also, you may enable WCF tracing as well (http://msdn.microsoft.com/en-us/library/ms733025.aspx).

    btw, the order of the tables in the designer generated code is based on the order of the tables in the Designer. By default, the tables are listed in alphabetical order in the Designer but there's an up and down arrow to change the ordering of the tables.

    cheers,

    junet
    Friday, March 5, 2010 4:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yeah but that absolutely does not work in a parent-child relationship I found out.  If you put the parent first then the child you are fine until you try to sync deleted rows.  Then you get foreign key errors.  That is why I removed my relationships. 

    Anyways, yeah thanks, I just need to get a copy of that database and try find what's going on.  Thanks.
    Travich
    Friday, March 5, 2010 5:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello travich,

    Have you tried adding the tables in the reverse order?

    So, if T1 has foreign key reference to T2, the correct order to add the tables to DbSyncScopeDescription object is

    T2 then T1.

    Hope this helps.

    Patrick

    Friday, March 5, 2010 6:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Right but doesn't that entail messing with the designer file?  I was trying to avoid messing with the designer file -- I've already made one change I guess I could have made on more...
    Travich
    Friday, March 5, 2010 7:40 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I have a VERY big clue if someone can help -- the problem is that it's sitting there trying to apply the same failed row over and over again on a duplicate key.  Here's my code:

            void PowerEFSRClientSyncProvider_ApplyChangeFailed(object sender, Microsoft.Synchronization.Data.ApplyChangeFailedEventArgs e)
            {
                         
    e.Action = Microsoft.Synchronization.Data.ApplyAction.RetryApplyingRow;            
            }

    I thought this would retry ONCE not again and again.  How can I just tell it to SKIP what it thinks it needs to keep applying?
    Travich
    Friday, March 5, 2010 10:28 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    you can modify your event handler to check for the type of conflict (check the parameter ApplyChangeFailedEventArgs e)


    the FK error will be have a conflict ype of ConflictType.ErrorsOccured (i.e.,  if (e.Conflict.ConflictType = ConflictType.ErrorsOccured) ), then if you dont want to do a retry, you can set e.Action = Microsoft.Synchronization.Data.ApplyAction.Continue

     

     

    Saturday, March 6, 2010 2:18 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    As you know we've talked before -- how can I get rid of what's stored in the conflict table when I continue?  That info is what caused that memory leak for me.
    Travich
    Saturday, March 6, 2010 5:30 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    that will be under SyncContext.GroupProgress.TablesProgress.

    Here;s a code snippet on how i go about clearing it.

     //assuming the conflicts had been handled on the service side
 // we don't need to download them anymore, so let's clear the conflict collection
 foreach (SyncTableProgress syncTableProgress in syncContext.GroupProgress.TablesProgress)
 {
      syncTableProgress.Conflicts.Clear();
 }
    Monday, March 8, 2010 3:13 PM