On May 6, 2008, at 11:08 PM, Scott Hess wrote: > > I suppose in DELETE mode, SQLite will delete the journal for you, but > I don't think it would hurt to do it yourself...
No, it's deadly to do it yourself. That is my point. Unless you very carefully analyze the lock state of the database file and the content of the rollback journal, you cannot know whether or not it is safe to delete the journal file. If it is not safe to delete the journal file and you delete it anyway, the database will go corrupt. The code needed to determine whether or not it is safe to delete the journal file is non-trivial. Never, ever, ever delete a journal file on a database that you care able. Let SQLite delete it for you if you want the file to go away. Deleting journal files will eventually result in corrupt databases, regardless of what journaling mode you are using. In PERSIST mode, you can probably get away with deleting the journal file in many cases, but if you do it habitually, you will eventually end up corrupting your data. Hence, an advantage of DELETE journaling mode is this: If a journal file exists you know that file is essential to the correctness of the database. In PERSIST journaling mode, you never know and you delete the file at your peril. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
