locked
Compact Framework Sync Failures RRS feed

  • Question

  • Hi all,

    Posted in wrong forum maybe (just in the regular compact framework forum) and haven't had any suggestions in a week.  Figured posting this in the correct area may help.

    Using Sync Services for ADO.NET, Windows Mobile 6.5.3, followed the tutorial for occasionally connected smart devices.

    Over 100 units running this software, everything works great in the office and at many locations.  Some locations have performed thousands and thousands of syncs without problem, some seem to experience this more often than not.  Once this error starts occurring the local database will never sync again - I have to replace their bad SQL CE database with a fresh copy.  I cannot replicate this no matter how many times I try but I DID save a few of the busted databases without merging trapped records.  I'm now trying to make these local databases sync by changing code in a test copy of the software.  Thought change tracking was set too short so I upp'd it to 40 days, no difference.  Removed all web proxy timeouts to give it as long as it needs.  Takes maybe 5-10 seconds before I get this:

    System.Reflection.TargetInvocationException: TargetInvocationException ---> System.Reflection.TargetInvocationException: TargetInvocationException ---> System.Net.WebException: WebException
       at System.Web.Services.Protocols.SoapHttpClientProtocol.doInvoke(String methodName, Object[] parameters, WebClientAsyncResult asyncResult)
       at WID_REC.wbRef.WIDSyncService.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.Synchronization.Data.ServerSyncProviderProxy.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
    Any suggestions?  Again, it works absolutely perfectly at some locations.  Others, not so much.  I hold my syncagent.synchronize in a try/catch.  I greatly appreciate any help - this is a state govt project that is quickly tanking with over half a million invested.  All sync tables are set to uploadonly.
    Tuesday, August 7, 2012 1:53 AM

Answers

  • if you the initial data in your sql ce database was created when your SQL Change Tracking was still set to 2 days, that means, SQL Change Tracking would have cleared change tracking information in 2 days time.  this renders your SQL Ce database outdated on the 3rd day.

    try profiling the SelectIncremental commands and run them manually with the same anchor values from the profiler and see it raises this message : "SQL Server Change Tracking has cleaned up tracking information for table"

    • Marked as answer by BKAY2011 Friday, August 31, 2012 8:31 PM
    Tuesday, August 21, 2012 5:56 AM

All replies

  • have you enabled includeExceptionDetailInFaults in the WCF config so it shows more exception details?

    likewise, have you tried increasing the message sizes?

    Tuesday, August 7, 2012 3:26 AM
  • Thanks for your response June, many of your posts that I stumbled upon via Google have been of great help with this project!

    I do have     <serviceDebug includeExceptionDetailInFaults="True" />  in my App.config

    The error I'm catching is a bit longer than what I pasted so I've included the rest.  Not sure what you mean by increasing message sizes if this is not all inclusive.

    I ran a little tool I made that compares record ID's (GUID column) on the server to the GUIDs of the SQLCE database and removes records that made it to the server.  Thought was to remove duplicates prior to sync.  Copied this database back on to the device and the same error appeared.  I then deleted all records from the local DB and copied back - sync worked.  So, the database itself isn't corrupt in any way to my knowledge. 

    Thanks again for your help!

    System.Reflection.TargetInvocationException: TargetInvocationException ---> System.Reflection.TargetInvocationException: TargetInvocationException ---> System.Net.WebException: WebException
       at System.Web.Services.Protocols.SoapHttpClientProtocol.doInvoke(String methodName, Object[] parameters, WebClientAsyncResult asyncResult)
       at WID_REC.wbRef.WIDSyncService.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.Synchronization.Data.ServerSyncProviderProxy.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.Synchronization.Data.ServerSyncProviderProxy.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at Microsoft.Synchronization.SyncAgent.UploadChanges(SyncGroupMetadata groupMetadata)
       at Microsoft.Synchronization.SyncAgent.Synchronize()
       at WID_REC.RL.mn_Upload_Click(Object sender, EventArgs e)
       at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
       at System.Windows.Forms.Menu.ProcessMnuProc(Control ctlThis, WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContextMenu.ProcessMnuProc(Control ctlThis, WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContainerControl.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Form.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.ML.ShowContextMenu(IntPtr hmnuThis, IntPtr hwnTempOwner, Int32 x, Int32 y)
       at System.Windows.Forms.ContextMenu.Show(Control ctrl, Point pos)
       at WID_REC.Main.theList_ButtonClick(Object sender, CellEventArgs e)
       at Resco.Controls.AdvancedList.AdvancedList.OnButton(ButtonCell c, Row r, Point index, Int32 yOffset)
       at Resco.Controls.AdvancedList.AdvancedList.OnMouseUp(MouseEventArgs e)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContainerControl.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
       at System.Windows.Forms.Application.Run(Form fm)
       at WID_REC.Main.Main()
    
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.Synchronization.Data.ServerSyncProviderProxy.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.Synchronization.Data.ServerSyncProviderProxy.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at Microsoft.Synchronization.SyncAgent.UploadChanges(SyncGroupMetadata groupMetadata)
       at Microsoft.Synchronization.SyncAgent.Synchronize()
       at WID_REC.RL.mn_Upload_Click(Object sender, EventArgs e)
       at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
       at System.Windows.Forms.Menu.ProcessMnuProc(Control ctlThis, WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContextMenu.ProcessMnuProc(Control ctlThis, WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContainerControl.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Form.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.ML.ShowContextMenu(IntPtr hmnuThis, IntPtr hwnTempOwner, Int32 x, Int32 y)
       at System.Windows.Forms.ContextMenu.Show(Control ctrl, Point pos)
       at WID_REC.Main.theList_ButtonClick(Object sender, CellEventArgs e)
       at Resco.Controls.AdvancedList.AdvancedList.OnButton(ButtonCell c, Row r, Point index, Int32 yOffset)
       at Resco.Controls.AdvancedList.AdvancedList.OnMouseUp(MouseEventArgs e)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContainerControl.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
       at System.Windows.Forms.Application.Run(Form fm)
       at WID_REC.Main.Main()
    
       at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean verifyAccess, StackCrawlMark& stackMark)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.Synchronization.Data.ServerSyncProviderProxy.ApplyChanges(SyncGroupMetadata groupMetadata, DataSet dataSet, SyncSession syncSession)
       at Microsoft.Synchronization.SyncAgent.UploadChanges(SyncGroupMetadata groupMetadata)
       at Microsoft.Synchronization.SyncAgent.Synchronize()
       at WID_REC.RL.mn_Upload_Click(Object sender, EventArgs e)
       at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
       at System.Windows.Forms.Menu.ProcessMnuProc(Control ctlThis, WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContextMenu.ProcessMnuProc(Control ctlThis, WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContainerControl.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Form.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.ML.ShowContextMenu(IntPtr hmnuThis, IntPtr hwnTempOwner, Int32 x, Int32 y)
       at System.Windows.Forms.ContextMenu.Show(Control ctrl, Point pos)
       at WID_REC.Main.theList_ButtonClick(Object sender, CellEventArgs e)
       at Resco.Controls.AdvancedList.AdvancedList.OnButton(ButtonCell c, Row r, Point index, Int32 yOffset)
       at Resco.Controls.AdvancedList.AdvancedList.OnMouseUp(MouseEventArgs e)
       at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.ContainerControl.WnProc(WM wm, Int32 wParam, Int32 lParam)
       at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
       at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
       at System.Windows.Forms.Application.Run(Form fm)
       at WID_REC.Main.Main()

    Tuesday, August 7, 2012 4:57 AM
  • do you have the includeExceptionDetailInFaults set on the WCF server side config as well?

    by message size, am referring to maxReceivedMessageSize, maxBufferSize, etc...

    if the client database is corrupted, i would expect it to fail much earlier when selecting changes.

    try enabling sync framework tracing as well on the server side, see: http://msdn.microsoft.com/en-us/library/cc807160.aspx

    Tuesday, August 7, 2012 5:16 AM
  • June,

    This is partially resolved, I noticed that if I saved a bunch of new data to a non-syncing database and then removed everything prior to those records then the database would sync again.  I googled around and I guess I needed to reinitialize the client database.  I don't know why this happens in a short period of time, change tracking is set to 40 days on the server but the initial client database was generated when I had it set to 2 days.  I wrote a bunch of code to give field users a work around, every successful synchronization attempt updates a value in the registry (with the most recent record's date).  If they screw up and don't sync for a while then it's assumed that all records after that last sync date are stuck.  I select those records and one by one the code loops through, submitting each record and deleting it from the client database immediately after.  Since this is all UploadOnly and I'm sick of problems, they'll just have to deal with it.  The records really serve them no purpose afterward and if they really want to look up a specific record (actually, a boat's registration #) then there's already a section to search the server for boat history. 

    Not an elegant solution and I'm sure it'll blow up in my face again at some point, but it's a heck of a lot better than me driving around to replace client databases or trying to teach computer illiterate folks how to install the data restoration program I had written for PC. 

    Thanks again for all your help.  I was able to enable tracing on the server side and have it set to verbose.  I know that this can cause performance issues but it's a somewhat slow day for inspections and the log has only grown to 300kb in the last hour.

    When I try to sync one of the problematic databases there is no new activity in this log at all.  If I use 'DELETE FROM CODNR_SINSPECTIONS' to wipe out the records of this problematic SQLce db and reload to device then I can resume logging inspections and it syncs that second without any issues.

    I would assume then that there's a problem on the client's side as the server isn't logging anything, not even an attempt from a client ID.  The error remains the same (as posted above).  There's a varying length of time before it says that the upload failed and saves this error, usually between 2 and 10 seconds, so it's doing something...  Again, all I have to do is copy a blank client database on to the unit or delete all records from the client's database and then I can resume.  All connectivity settings stay the same during this so that's literally the only change occurring.

    I tried to enable tracing on the client (trace.config.txt in the application's directory on the device) which appears exactly as follows:

    <?xml version="1.0" encoding="utf-8" ?>
    
    <configuration>
    
    <traceSettings>
    
    <add key ="FileLocation" value="Trace_OCS.txt"/>
    
    <add key ="LogLevel" value="4"/>
    
    </traceSettings>
    
    </configuration>

    but when I do this:

       Dim trace As String = ""
            trace = trace + ("** Tracing Levels Enabled for this Application **") + vbNewLine
            trace = trace + ("Error: " + SyncTracer.IsErrorEnabled().ToString()) + vbNewLine
            trace = trace + ("Warning: " + SyncTracer.IsWarningEnabled().ToString()) + vbNewLine
            trace = trace + ("Info: " + SyncTracer.IsInfoEnabled().ToString()) + vbNewLine
            trace = trace + ("Verbose: " + SyncTracer.IsVerboseEnabled().ToString()) + vbNewLine
            MsgBox(trace)
    all return false.  I wanted to at least see if this was working before I spent the time creating the utility class found in the instructions you linked above.  Am I missing something?  I assume that tracing on the device vs the server generate different things and my problem very well could be captured on the client's log if I could get this figured out.  If I need to complete more steps before checking the above then I'll do that.

    No 'TRACE_OCS.txt' is saved anywhere on the device though maybe that won't be created until I finish the utility class and add in all the other steps from the instructions.

    Thanks!



    • Edited by BKAY2011 Saturday, August 18, 2012 4:57 AM
    Friday, August 17, 2012 11:07 PM
  • OK, So I'm assuming that things are going awry because the clients don't sync often enough (due to being away from access point, flakey cell data service, whatever).  I have change tracking set to 40 days on the server, but had it set to two days when I initially added the web service to my smart device project.

    I couldn't find a query that would allow me to increase this on the SQL ce database, just for the whole server.  Then I stumbled across sync provider 'retentiondays' and was able to have it tell me this length- 10 days.  Apparently this is the default.

    Are these the same things?  For my still working databases out in the field, can I just do one of these maneuvers to increase it?  I'm assuming this wouldn't fix the ones refusing to sync currently, but it could help me avoid the problem in the future.

    Partial Public Class WIDClientSyncProvider
        Inherits Microsoft.Synchronization.Data.SqlServerCe.SqlCeClientSyncProvider
        
        Public Sub New()
            MyBase.New()
           If Me.RententionDays <> 40 Then Me.RetentionDays = 40
            Me.ConnectionString = ("Data Source=" _
                        + (System.IO.Path.Combine(System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly.GetName.CodeBase), "WID.sdf") + ";Max Database Size=2047"))
        End Sub
    Thanks!


    Monday, August 20, 2012 10:34 PM
  • if you the initial data in your sql ce database was created when your SQL Change Tracking was still set to 2 days, that means, SQL Change Tracking would have cleared change tracking information in 2 days time.  this renders your SQL Ce database outdated on the 3rd day.

    try profiling the SelectIncremental commands and run them manually with the same anchor values from the profiler and see it raises this message : "SQL Server Change Tracking has cleaned up tracking information for table"

    • Marked as answer by BKAY2011 Friday, August 31, 2012 8:31 PM
    Tuesday, August 21, 2012 5:56 AM
  • Shoot, I feel that's the case then - makes so much sense.  The sites with the least of problems have the best connection to the internet and operate in close proximity to the hotspot.  Some places have great connection strength but absent minded employees that don't turn on the wireless.  Wouldn't surprise me if they forget for multiple days at a time and the clues all add up to this.  So even though when I get the RetentionInDays value from the sync provider (always returns 10 even if I change it at load) I can disregard this?

    Will double check that all tables are set for much longer and then re-run the WCF service local db cache, re-add to project, do all of those fun changes required to make it work on the device, reupload the wcf service, and package this new blank SDF with my next update.  Dunno if any of that is overkill but I'm hoping to do this right finally :)

    Do you happen to know how long I can set change tracking before it becomes a problem?  The main table has about 120,000 records and now that the boating season is tapering off we're only seeing ~500 records a day on week days and ~2000 on weekends.

    Thanks so much, you answered a question that months of googling could not.


    • Edited by BKAY2011 Tuesday, August 21, 2012 7:32 PM
    Tuesday, August 21, 2012 7:14 PM
  • JuneT, hopefully you could answer me just one last quick question -

    I like to deploy blank client databases since this is pretty much always going to be an uploadonly situation.  When I first made the WCF service and local db cache it was before we had any data, so for months now I've been deploying the blank SDF that was generated by the designer initially.  This is no longer the case so when I went to recreate everything I started pulling massive amounts of data on the first sync.  The old database was ~404kb, this one swells to 40megs and when I delete all records from my three main tables it remains at about 17mb.  I don't think I can deploy that - would kill the cell data allowance for nothing.  Something else is lingering to make the database so enormous and I can't figure out how to get rid of it. 

    Is there a way to shrink this? (already tried clean, shrink, etc).. or anything I can do to get back to a small blank database on my clients initially?  I keep finding the inverse of this question, where people want to deploy clients preloaded.  I thought maybe after a sync (uploadonly) that it might clear crap out but this doesn't seem to be the case, out of memory in fact.  Just enabled batching so that will hopefully alleviate this problem but I'll still have a swollen database with no data in it.  I don't know why it's thinking so long on an uploadonly anyway with no records in the one table I left in my synctables collection.  Keep freaking out that I'm going to wipe out the actual info on my server doing this.

    Guess the last q is - can I reuse my old database anyway?  I uploaded the new WCF service and added a new web reference to the client, is that enough to have it start tracking changes greater than the 2 days or is that somehow buried in the SDF file that's automatically generated?

    Thought I was so close!

    Tuesday, August 21, 2012 10:56 PM
  • the SQL CE database has change tracking enabled. the change tracking is for recording inserts/updates/deletes that happens. when you delete data, you still have change tracking metadata for the deleted rows, thus, the db size still shows a bigger value.

    the SQLCeClientSyncProvider has a RetentionInDays property. this property is completely independent of the retention policy of your SQL Server (afaik). There is no explicit call to clean up the metadata on the client. This cleanup is done as part of a sync session. when you sync, it will do clean ups as well. the smallest value for the RetentionInDays is 1 day.

    if you are recreating your WCF anyway, just include a blank database instead.

    to optimize scenarios where its taking long to do a sync even if when there are no changes to upload, try this:Synchronization Services for ADO .NET for Devices: Improving performance by skipping tables that don’t need synchronization

    Wednesday, August 22, 2012 1:44 AM
  • Thanks much - I ended up starting from scratch with all of this - all new tables, WCF service, and client side files including new .sdf

    Since I was doing this all over again I figured I'd include a few tables and set them to sync the entire table each time since they're not big...

    Example, a locations table for our boat inspection stations, about 100 in total.  This contains a location ID (identity), location abbreviation, full name, and GPS position.  Very light and if I make a dummy project that just displays this table in a datagrid on the device it takes maybe two seconds to load everything.

    In a test line of code in the main application I created a new webserviceproxy, remote provider, and sync agent.  I did a syncagent.configuration.synctables.clear, then added just this one locations table to sync.  I have a progress bar tied to the session progress and when I call dim stats = syncagent.synchronize, it sits for maybe 2 seconds at 3%, then goes to 55% and never completes.  The handheld becomes severely lagged and I have to close it via task manager.  The following is in the client.designer.vb:

    Me.TableName = "tbl_Locs"
                Me.SyncDirection = Microsoft.Synchronization.Data.SyncDirection.Snapshot
                Me.CreationOption = Microsoft.Synchronization.Data.TableCreationOption.DropExistingOrCreateNewTable

    Any clue what could be going on here?  Never throw an error, even after waiting for 20 minutes.  Never get a message box with the stats suggesting it's complete.  I also added a message box to appear in the StateChanged of the syncagent to tell me when it's changed back to ready, and it never appears.  Lastly, since the device is so laggy I assume something is still going on.

    Edit: Looked at the log being created by the server.  It seems like the same table just tries to synchronize over and over again.  I attempted to just sync the inspections table (the only one in the bunch not listed as syncdirection.snapshot, instead it's bidirectional) and it worked fine.  Any of the other tables listed as snapshot like above will keep looping over and over again.  The following snippet from the server's log is the same stuff that repeats every 10 seconds or so.  - I had every table included to sync now, and bait types is the first one.  The same loop was happening when I just had a single table included (the locations table mentioned above)

    INFO   , w3wp, 16, 08/28/2012 21:30:24:932, Connecting to server using string: Data Source=(removed the cstring)
    INFO   , w3wp, 16, 08/28/2012 21:30:24:932, ----- Server Enumerating Changes to Client for Group "tbl_BaitResultsSyncTableSyncGroup" -----
    INFO   , w3wp, 16, 08/28/2012 21:30:24:932,               Client Id: 5f79f036-2317-4979-8bf3-5743c83583d4
    INFO   , w3wp, 16, 08/28/2012 21:30:24:932,    Mapped Originator Id: 0
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932, Using Command: usp_GetNewBatchAnchor
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932,    Parameter: @sync_last_received_anchor Len: 8 Value: 10600
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932,    Parameter: @sync_max_received_anchor Value: Skipped since Not Input/InputOutput
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932,    Parameter: @sync_new_received_anchor Value: Skipped since Not Input/InputOutput
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932,    Parameter: @sync_batch_size Len: 4 Value: 20
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932,    Parameter: @sync_batch_count Len: 4 Value: 6770
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:932, 
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948, 
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948,    ----- Enumerating Inserts for Table tbl_BaitResults -----
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:948, Using Command: SELECT * FROM dbo.tbl_BaitResults
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:948, 
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948,       Changes Enumerated: 3
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:948,       Insert for row with PK: Result_ID="1" 
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:948,       Insert for row with PK: Result_ID="2" 
    VERBOSE, w3wp, 16, 08/28/2012 21:30:24:948,       Insert for row with PK: Result_ID="3" 
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948,    --- End Enumerating Inserts for Table tbl_BaitResults ---
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948, 
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948,    ----- Enumerating Updates for Table tbl_BaitResults -----
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948, 
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948,    ----- Enumerating Deletes for Table tbl_BaitResults -----
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948, --- End Server Enumerating Changes from Client for Group "tbl_BaitResultsSyncTableSyncGroup" ---
    INFO   , w3wp, 16, 08/28/2012 21:30:24:948, Closing connection to server
    I'm thinking this very well may have been the issue on two of my units that had Verizon data service, they didn't get deployed until late in the season but were kicking out ridiculous bills for months prior.  Maybe I had an earlier build of the software that I was testing snapshot and the like on and they'd just do this loop until they ran dead.  July's bill for just two units that weren't even in the field was almost $8,000.  Bet Verizon was happy :|



    • Edited by BKAY2011 Tuesday, August 28, 2012 9:39 PM
    Tuesday, August 28, 2012 7:21 PM
  • Snapshot doesn't store anchors so it will always grab all rows.

    when you try to get a table as snapshot, then get a snapshot again on second sync, its doing a full sync, not incremental update since there are no anchors.

    have a look also at this post to see how you can further reduce the payload: Sync Framework WCF-based Synchronization for Offline scenario – Using custom dataset serialization

    Thursday, August 30, 2012 11:21 AM
  • Simply put, you are awesome.  Hope this thread can help others as much as it has helped me.

    Brandon

    Friday, August 31, 2012 8:33 PM