Thank you for your answers. To reply to Mr. Hipp and Mr. Morras :
Yes your are right, verifications made, the process is I/O bound. (CPU activity jumps from 1% - 2% at iddle time to 5-6 % when a "PRAGMA quick_check" is processed). Thank you for pointing to me the right track ! About downloading latest trunk version with enhancements on this subject, thanks, the offer is appreciated, but unfortunately there is no skills in C langage here, so will wait the next release. I can confirm mmap brings big improvements in speed processing of "PRAGMA quick_check" (roughly a 40% gain in time consumming). "Login" in the app. is effectively the startup process. There is no client-server logic in the usual sense. If multi-user capability is needed (in the context of a small workgroup) on the same installation, each user launches a new and separate instance of the same application sharing the same db. (efforts are done to prevent concurency pb). To answer to Mr Slavin : Yes, a few years ago on a test db, used for developpment and testing purpose, "PRAGMA quick_check" reported some anomalies (didn't had the time to investigate further - but hardware failure suspected). What surprised me was, despite the presence of (few) anomalies reported, the apparent behaviour seemed "normal". I suppose that if the corrupted pages are not visited by the library (for example data rarely processed like "historical" data), everything seems "OK". I concluded that a "running" db with some pb at the file level can live (for a random limited time) with no visible issue . Your question on the good time to process a check on the db file sounds like a "phylosophical" question not easy to answer. Why doing this check before calculus processing is preferable to, for example, before/after an update on an employee's personnal address ? Would the db be more inusable only in the first case ? Here, the checks are done at minima and guided by top-most priorities (backup and restore use the Tcl API of Sqlite and are managed at application level, as some process ask for a backup made before) : 1) garantee a restore operation allways gives an sane db 2) don't allow a backup if db file have pb (wasted time + dangerous illusion) 3) check the db file at minima once per usage. I agree that a db check at user log-out time is logically equivalent as processed during log-in time and provides a better user experience. But we have several pb here : - there is no garantee that the user exiting the application will be the first one who logs in on next startup. - the application can process automatic log-out (depending on elapsed time of user inactivity). - In case the result of a quick_check will not be OK, it is desired that someone takes appropriate action as soon as possible. Jean-Marie
