I am working on survey where users count the number of bike/peds encountered over a two hour period. In planning for worst-case scenarios, my client is worried about losing data collected before submission of the survey. One scenario is that a user's device stops working (battery dies maybe) or the app freezes up after collecting, say, 1.5 hours of data. In that case, would any of the survey data have been written to the sqlite database by then. Or does the write to the database happen only when the user clicks the 'done' button - and thus in my example scenario all the collected data are lost?
Any thoughts about ways to mitigate data loss when conducting a long-transaction type of survey? We have played around a bit with regularly saving 'drafts' of the survey, but in the time it takes to stop, save, and restart the survey its possible that several to many bikes/peds passed without being counted.
Thank you
Solved! Go to Solution.
Hi Tom. At this moment in time, Survey123 only stores your data in the device when you either save a draft or hit the submit button to send your data to the outbox or sent folders. Regularly saving your work as a draft is a good practice, but I understand it may not be practical when you are capturing data in a hurry. We have discussed internally the idea of enabling an auto-save function so every time you change or add a new response your data will be automatically saved for you. So far we have not implemented this function, but it looks like you could make good use of it. I added your use case to our back-log.
Hi Tom. At this moment in time, Survey123 only stores your data in the device when you either save a draft or hit the submit button to send your data to the outbox or sent folders. Regularly saving your work as a draft is a good practice, but I understand it may not be practical when you are capturing data in a hurry. We have discussed internally the idea of enabling an auto-save function so every time you change or add a new response your data will be automatically saved for you. So far we have not implemented this function, but it looks like you could make good use of it. I added your use case to our back-log.
Thank you for the info.
I'd be glad to add this to the ArcGIS Ideas site if that would help move the issue up the backlog list