|
Hi, I have a windows mobile .net app that uses an ultralite (v 16) database. The handheld has a cellular connection and will replicate data back to the consolidated database. It only uploads data. In a few instances, the cellular connection is lost after the upload has started but before the data reaches the consolidated database. I'm assuming this is happening because the record in the ultralite database will not upload later - during a full, connected replication. If I manually modify the record, it will send an update transaction but it will never send the original insert transaction. It's like the ultralite database has marked that record as sent. I looked for a sync switch or a mobilink switch I could set for this but didn't come up with anything. Is there anything I can do about this? Thank you in advance! Paula |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 25 Apr '17, 10:15
question was seen: 1,302 times
last updated: 25 Apr '17, 12:34
Your description indicates the row state management for that row no longer has a 'newly commited row, requires synchronization' status. That would mean your only option to force an insert to synchronize would be to delete, synchronize, and re-insert the data again.
Questions you might want to try to answer for yourself include:
1. Do we know that the row was really inserted on this remote devices and not just downloaded? 2. Is it possible it was uploaded earlier but there was some sort of transactional failure at the consolidated side (possibly due to a upload_insert script error/problem? or transactional control wrongly injected mid-sync?) 3. Were there any errors related to the synchronization history for this remote?Hi Paula,
What you describe here should not happen. UltraLite and Mobilink are very careful to preserve data. If UltraLite doesn't receive confirmation that the server has successfully committed the uploaded rows, it will ask the server on the next sync and resend them if required.
Said another way, UltraLite will not mark a row as "uploaded" until Mobilink confirms the row is safely committed to the consolidated database. Instead it marks the rows it sends as "uploaded but awaiting confirmation". If the server eventually acknowledges, then UL knows it can mark the row as "uploaded", otherwise the row goes back to "needs to be uploaded."
If you have found a bug, please provide all the reproducible information you can. Is it possible though that there's another explanation?