The core code is in place since about 2008. 


I took advantage of changes in SQLite over time, from using the shared cache to 
switching to WAL mode for databases which are not opened in read-only mode.

These changes were made between 12 and six months ago, and tested during beta 
tests and also in the wild. 

Most database damaged errors encountered over time could be pinned to power 
failures, disk or network problems. 

But a too high number of recent reports (couple of months) could not be linked 
to any hardware problem or power failure. 


My application uses multiple concurrent threads, but each thread works with its 
own instance of SQLite (on the same database). Transactions are used to improve 
performance and for control 

flow. Every error returned by SQLite is logged to the log file. If a SQLite 
function returns the dreaded “disk image malformed” error, my application 
immediately stores that error and remembers it – the database is marked as 
defective and the user is notified as soon as possible.


My users run daily backups of all their important data, including the database 
so usually they can roll-back to the last known working backup and continue. 


I will implement Richard’s suggestions to gather more info to the log file. The 
next time a user reports the problem, we may get extra hints about why and when 
this happened.


Thanks for the great support and advice.


-- Mario


sqlite-users mailing list

Reply via email to