I ran into an interesting problem today having to do with a left-over journal
file.
When I first initialize my app, my general strategy is this:
- Delete src.db, tmp.db, dst.db
- Copy a static copy of my database (src.db) to a well-known temporary
place (tmp.db).
- Make some changes to the database (add some indexes, etc)
- If everything has succeeded, copy tmp.db -> dst.db
The theory (was) that if there are any crashes during the initialization
process, etc, that dst.db will never be valid and initialization will start
from ground zero on the next launch.
This fails, for the simply reason that if a crash occurs, a single file is
left-over at the next startup: dst.db-journal. And when the journal is there,
in conjunction with a fresh copy of the src.db, sqlite fails in various
manners, as might (or might not) be expected.
That background out of the way, three questions:
(1) Is there any API I can/should use to predictably get the name of
the journal file so that I can delete it, without "knowing" what is should be?
(2) Are there any changes that can/should be made to sqlite3 so that it
can identify the bogus journal in this scenario and discard it?
(3) Should there be a flag to open_v2, or something, that tells it to
discard any extant journal?
Thanks,
James
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
