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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
