On Tue, May 6, 2008 at 7:41 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote: >> Since PERSIST is likely to be faster than DELETE on >> most platforms, is there ever a reason *not* to use >> it? > > In PERSIST mode, you have two files associated with your database > instead of one. Whenever you move, copy, or rename the database file > you *must* also move, copy or rename the journal file to prevent > database corruption.
Even in DELETE mode, you can't (safely) do a move, copy, or rename without acquiring an appropriate lock (via BEGIN IMMEDIATE or better). That will create the journal file, so you already have to deal with it. In case of a move, you could either move it first (because the lock is on the database file), or delete it. In case of a copy, you just need to copy the database (the journal file is known to be empty at this point). I suppose in DELETE mode, SQLite will delete the journal for you, but I don't think it would hurt to do it yourself, in fact it should help avoid a race condition. If you move the database file then let SQLite delete the journal, someone else could have opened a same-named database in the meanwhile and conflicted with your journal file. By dealing with the journal file before the database file, this cannot happen because of the lock on the database file. -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
