Your aim appears to be to have data recovery from hardware and operating
system failures. That is beyond the power of Sqlite and needs to be
designed into your system or the hardware. Logginjg or replication onto
different media would provide the redundancy and diversity you seek.
Olaf Beckman Lapré wrote:
It depends on what gets corrupted. I found that alterring the data of the
tables itself didn't result in crashes but SQLite is very sensitive to
corrupted system tables and file headers. So the data is ussually
recoverable as long as the database can be brought into a readable state.
This means that the system headers should be repaired (ussually by looking
at other data in the file). If the system tables are damaged the application
could simply create a new database and start transferring data from the
tables into the new database.
There are many parent-child relationships in an e-mal client and a
relational database lends itself perfectly for this, apart from the
convenience of only having to manipulate a single file (both from a
developer and user perspective).
Olaf
----- Original Message -----
From: "Dave Dyer" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>; <sqlite-users@sqlite.org>
Sent: Thursday, August 17, 2006 7:45 PM
Subject: [sqlite] Re: fault tolerance
Most of us use email clients that store our mail as simple text files. An
SQLite database is no more likely to get corrupted than any other file.
I would stipulate that sqlite data is less likely to be corrupted due to
bugs in sqlite itself, or due to power failure or gross program crashes.
Good engineering is great, but it doesn't help the shuttle when a chunk of
foam hits the wing.
A sqlite database is more likely to be corrupted by bugs in the overall
application. Using sqlite is a lot more complex than just appending to a
text file, and because sqlite's data structures share address space with the
main application, they are vulnerable to whatever bugs are present in the
main application. I would also include program bugs which result in rogue
queries as corruption - one "update" with a poorly constructed "where"
clause can ruin your whole database.
Once a sqlite database is corrupted, you've got a mess with no clear path
to recovery, other than to revert to some previous backup of the entire
database.
On the other hand, in a file based application (such as a mail reader), In
any conceivable crash, I've got backups of individual files which I can
mix-n-match with whatever debris seems recoverable, and the individual mail
files, even if damaged, are intelligible.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
