Answered by:
Sync service for Devices: Performance loss if only selectincrementalupdates is defined (not selectincrementalinserts)?

Question
-
Hello
To put my question in short:
Will I have a performance loss if I only define SelectIncrementalUpdates and not SelectIncrementalInserts in a senario where the vast majority of the synchronized data rows will actually be inserts?
Background:
When I started to read on sync framework I came across an article (i think it was on sync guru) that gave the hint that if you have a SyncAdapter with syncdirection download only you don't have to specify any other select command than selecetIncrementalUpdates. Due to the cumbersome filtering control I've decided to only implement this.
During the course of our project the synchronization have become quite time consuming, and the majority of the time is spent on the devices, after the xml is parsed to the DataSet.
It recently hit me that only define selectincrementalupdates might be one cause for this. I.e. if the device receives a lot of data rows as updates when they don't exist in the target database it have to do two database commands for each rows. This is only a guess from my side - I haven't seen any detailed information about how SqlCeClientSyncProvider works internally.
Friday, March 26, 2010 9:42 AM
Answers
-
you can try enabling Sync Tracing and see if this message appears: "Retrying conflict by applying change as an Insert"
if it does, it actually does 3 commands:
1st-update - no row is updated, it will check if its a conflict
2nd-select - it will try to select the client row to populate the conflict object, this doesnt return a row since the row hasnt been inserted
3rd-insert - it then decides to do an insert
- Marked as answer by Joel Steen Timle Monday, March 29, 2010 11:00 AM
Saturday, March 27, 2010 2:54 AM
All replies
-
afaik, a conflict will be raised when an update is made for a non-existing row (ClientDeleteServerUpdate). you can however configure the update command to do an update if the row exists and do an insert if it doesnt.
you can verify if a conflict is being raised on the ApplyChangeFailed event on the client.
if it's treated as a conflict, then you'll also run into memory issues as well since conflicts are stored separately from the changes dataset.
also, if you configure for SelectIncrementalUpdates only, chances are you won't get the newly inserted rows unless they are updated.
Friday, March 26, 2010 10:09 AM -
afaik, a conflict will be raised when an update is made for a non-existing row (ClientDeleteServerUpdate). you can however configure the update command to do an update if the row exists and do an insert if it doesnt.
you can verify if a conflict is being raised on the ApplyChangeFailed event on the client.
if it's treated as a conflict, then you'll also run into memory issues as well since conflicts are stored separately from the changes dataset.
also, if you configure for SelectIncrementalUpdates only, chances are you won't get the newly inserted rows unless they are updated.
No, it does not raise a ApplyChangeFlailed event.
We have adjusted our selectIncrementalUpadet command to fetch all data that's needed.
Friday, March 26, 2010 1:55 PM -
you can try enabling Sync Tracing and see if this message appears: "Retrying conflict by applying change as an Insert"
if it does, it actually does 3 commands:
1st-update - no row is updated, it will check if its a conflict
2nd-select - it will try to select the client row to populate the conflict object, this doesnt return a row since the row hasnt been inserted
3rd-insert - it then decides to do an insert
- Marked as answer by Joel Steen Timle Monday, March 29, 2010 11:00 AM
Saturday, March 27, 2010 2:54 AM -
you can try enabling Sync Tracing and see if this message appears: "Retrying conflict by applying change as an Insert"
if it does, it actually does 3 commands:
1st-update - no row is updated, it will check if its a conflict
2nd-select - it will try to select the client row to populate the conflict object, this doesnt return a row since the row hasnt been inserted
3rd-insert - it then decides to do an insert
Thank you!
This was exactly what I needed to know. A first run of initial tests shows that this is one of the larger performance losses in our project.
Time for some more fun design of the syncadapters selection commands : )
Monday, March 29, 2010 10:59 AM