On 27 Jan 2016, at 8:51am, Bernard McNeill <bm.email01 at gmail.com> wrote:
> Situation: Under Linux/Debian, Sqlite opens an entirely valid DB, and runs > an entirely valid SQL transaction against that database. > Following a Commit, the application gets back a 'Commit Successful' code. > (Ignore any issues of disks returning hardware 'write done' flags > prematurely). We can ignore this, but almost all systems are set up that way. So we shouldn't. > There is then a power/OS failure. > > Using the standard defaults (which avoid WAL), is there any possibility > whatsoever of that last SQL transaction being lost? If all of these ... 1) there was a gap of a second or so for the writing commands to complete 2) the power failure doesn't cause spurious data to be written to disk 3) the power failure doesn't cause low-level disk format problems 4) the power failure doesn't physically damage the drive 5) some other part of the OS doesn't get confused and write over the database then you should have an uncorrupted database with the last transaction correctly written. Under these circumstances the database is held not just in the database file but partly in the journal file. If you analyse just the database file you may conclude that you have a corrupted database or that the most recent transaction has been lost. One of the jobs of the SQLite _open() commands is to notice that the database file and/or the journal file indicate that the database wasn't closed cleanly, and to rescue as recent as possible uncorrupted database. It will do this without informing the calling program. The calling program will just thing the database was fine to begin with. Simon.
