hi Simon, Thank you for your response.
On a couple of occasions, we have tracked down failures in our application to corruptions in the database. This was confirmed by viewing the database directly, as well as by integrity_check. As this has happened on at least 4 very different platforms, including high end HP servers, I don't know that I can attribute this to hardware. With a corrupt DB row(s), the application may can continue operating quite nicely for weeks or months, until someone happens to query for a dependency of the affected data. So rather than have things blow up on a customer at that point, the preferred approach would be to run a check e.g. once per day and notify the user to contact customer support if anything errant is reported by integrity_check. So my original question still stands about the side effects of integrity_check and whether it would interfere with the continuous 24/7, multiple-times-per-second access by our mission critical application. I have another post over at phxsoftware.com/forums concerning the corruption issue, but i can repeat it here if anyone is interested. -- View this message in context: http://www.nabble.com/Practicality-of-using-pragma-integrity_check-at-runtime-tp25455187p25463835.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
