Liz Steel wrote:

I am trying to do a similar sort of thing with my database. The only way I've found to fairly reliably create a corrupt database file is to pull the battery out of my laptop whilst my application is accessing the database....

I've just tried it, and I get a code 11 (SQLITE_CORRUPT) returned from the PRAGMA integrity_check command. Is this correct behaviour?

No, this is not correct. SQLite is suppose to survive an abrupt power loss with no loss of data. (Uncommitted transactions will be rolled back, but committed transactions should persist and be consistent.)

I believe that SQLite does survive power loss without problems
on Linux.  However, I have received reports that the windows API
function FlushFileBuffers() sometimes lies and does not really
flush contents to the disk surface as it claims it does.  This
is just hearsay - I have not independently verified those reports.
If FlushFileBuffers() does lie and a power loss occurred in the
middle of a COMMIT, then database corruption is possible on
windows.  This is a bug in the OS and there is not anything
SQLite (or any other database engine) can do about it.

There was a bug in SQLite version 2.8.12 that could cause
database corruption if a power loss occurred at a particularly
inauspicious moment in the middle of a COMMIT.  That problem
was fixed with version 2.8.13.

If you are seeing database corruption following power loss
on Linux with SQLite version 2.8.13, please let us know about
it right away.  If you are seeing corruption on Windows, let
us know there too - the problem might be the FlushFileBuffers()
bug or it might be something else - either way we want to

-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to