How to ensure all library changes are flushed to database
Answered
sometimes after extensive library (track and/or) changes, then further map work, the app crashes, and upon restart it's discovered some changes were lost, not written back to the database. other than an exit & restart, is there a quicker way to ensure all mods have been safely written?
The same question
Hi Andrew,
I'm afraid it's not possible to say straight away if all mods were safely written. We would need to know the cause of the app crash, all events preceding (or leading to) the crash and so on. So please when someting like that occurs, report it immediately according to the instructions in https://docs.locusmap.app/doku.php?id=manual:faq:issue_reporting. Thanks a lot!
Hi Andrew,
I'm afraid it's not possible to say straight away if all mods were safely written. We would need to know the cause of the app crash, all events preceding (or leading to) the crash and so on. So please when someting like that occurs, report it immediately according to the instructions in https://docs.locusmap.app/doku.php?id=manual:faq:issue_reporting. Thanks a lot!
Thanks Michal, but maybe you misunderstood the question - I can guarantee the database is up-to-date by exiting Locus. But is there a faster method?
.
Doing a crash report is often not convenient, certainly when outside navigating, and to be useful to you, takes an amount of time to write (I've done plenty before).
Thanks Michal, but maybe you misunderstood the question - I can guarantee the database is up-to-date by exiting Locus. But is there a faster method?
.
Doing a crash report is often not convenient, certainly when outside navigating, and to be useful to you, takes an amount of time to write (I've done plenty before).
Do you mean some "reload" or "refresh" button in the library? I'm afraid I don't know about any... all changes should be written in the library immediately after executing the change. Unless the process is disrupted by something else, like a crash.
Do you mean some "reload" or "refresh" button in the library? I'm afraid I don't know about any... all changes should be written in the library immediately after executing the change. Unless the process is disrupted by something else, like a crash.
"all changes written immediately" - that's my point - assuming sqlite database, inserts or updates are generally never written immediately unless a transaction; any crash & the last few need to be done again
"all changes written immediately" - that's my point - assuming sqlite database, inserts or updates are generally never written immediately unless a transaction; any crash & the last few need to be done again
I've verified this with @Menion : all changes to tracks, routes and points are immediately written into the database. Unless the process is interrupted by a crash. That's why we need as much as possible info about the actions leading to the crash. If possible, including your user ID or bugreport.
I've verified this with @Menion : all changes to tracks, routes and points are immediately written into the database. Unless the process is interrupted by a crash. That's why we need as much as possible info about the actions leading to the crash. If possible, including your user ID or bugreport.
Hmm. Interesting. The last time I had made 3 or 4 changes in the library, moved between folders etc. but later (not immediately) while dragging around the map, there was a crash, then on restart the changes were lost. Not the 1st time. Not often. But I know it happens. Often it's simply not convenient to do a bug report sorry.
Hmm. Interesting. The last time I had made 3 or 4 changes in the library, moved between folders etc. but later (not immediately) while dragging around the map, there was a crash, then on restart the changes were lost. Not the 1st time. Not often. But I know it happens. Often it's simply not convenient to do a bug report sorry.
I understand, I ride a bike too and when there is a problem with Locus there's no time to deal with it. But when something happens when fiddling with the library on your sofa... it's another story. Anyway, thanks a lot for your cooperation.
I understand, I ride a bike too and when there is a problem with Locus there's no time to deal with it. But when something happens when fiddling with the library on your sofa... it's another story. Anyway, thanks a lot for your cooperation.
Hello Andrew,
may you write me here a "user ID" from the app (about app > user ID)? Crashes should be (not always as Firebase service we use seems not to be 100% reliable) send to our server, so if you write me your ID and the day it happen, I may try to find the reason of the crash. Thanks.
Hello Andrew,
may you write me here a "user ID" from the app (about app > user ID)? Crashes should be (not always as Firebase service we use seems not to be 100% reliable) send to our server, so if you write me your ID and the day it happen, I may try to find the reason of the crash. Thanks.
Not online Firebase service, I think local sqlite database? I think all databases cache/ batch updates to backend? I was not using cloudsync. But if useful 046392f35. Maybe in the app make this ID copyable with long tap.
/Android/media/menion.../data/database/*.db-journal or db-wal
regards Andrew (in bus shelter on side of quiet French road)
Not online Firebase service, I think local sqlite database? I think all databases cache/ batch updates to backend? I was not using cloudsync. But if useful 046392f35. Maybe in the app make this ID copyable with long tap.
/Android/media/menion.../data/database/*.db-journal or db-wal
regards Andrew (in bus shelter on side of quiet French road)
Replies have been locked on this page!