On 19 Jan 2011, at 6:43pm, Dustin Sallings wrote: > On Jan 19, 2011, at 2:35, Richard Hipp wrote: > >> No. The WAL has to be in the same directory as the original database. >> Otherwise, the process that tries to recover from a crash or power failure >> won't know where to find the WAL file. > > I understand how it's opening it. This is more about how the file is > used. > > If I could convince SQLite to open the WAL in a location other than in > the same location as the main db, would this cause reliability problems?
The problem is not with the session which creates the WAL file, its with the one that has to clear up after any crash. With things as they stand, every application which uses sqlite3 looks for a journal file in the same place. So if your application (or the computer) crashes and someone uses a different application next to open the database file, it will definitely be able to find the journal file and restore the database to an uncorrupted state, right after a COMMIT, just where you'd want it. This happens a lot: after a crash instead of restarting the normal application, someone uses the sqlite3 command-line utility or some sort of database viewer to see what state the data is in. With the journal in a predictable location SQLite will handle this correctly no matter what application they use. If you do something special to keep your journal file in a different place, these other sqlite3 applications won't find it. So they'll just find a corrupt database file, and are less likely to be able to figure out how to restore to a COMMIT point or a SAVEPOINT. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
