Michael Hunley wrote:
At 03:43 PM 12/22/2004, you wrote:
See section 6.0 in http://www.sqlite.org/lockingv3.html.
That article is on SQLite version 3, but the methods for
corrupting a database apply equally well to version 2.
Thanks. Unfortunately, none of these seem terribly likely. The user
reported that nothing unusual occurred. The corruption occurred after
installing some new software on his Palm which created a new entry in
the main table (DBBackup). He is an IT guy, so reasonably
knowledgable. He claims that he hasn't had any incidents of disk
corruption to date.
Short of writing randomly into the database file, is there any other
software means I could corrupt the db than to write binary data without
encoding it? Is there any way to tell if that is what likely occurred
if I trace into the validation pragma query?
Inserting binary data without encoding it should *not* corrupt the
database. It might make it difficult to get your data back, but
other records in the database should be uneffected and the kinds
of errors you were seeing from PRAGMA INTEGRITY_CHECK should not
occur.
A stray pointer or a buffer overrun in the application that
SQLite links with might corrupt some internal SQLite data
structures which could lead to database corruption. Experience
suggests that the more likely outcome is a segfault, but corruption
is a distinct possiblity.
We have not seen any SQLite bugs leading to database corruption
in about a year (version 2.8.12) and SQLite has been heavily
used since then. This could be some obscure SQLite bug, but
that seems unlikely. It might be a bug that is only manifested
on your PalmOS port, which is not a standard SQLite distribution.
Corruption can appear in a database long before you notice it.
Until this problem is tracked down, you might consider modifying
your code to do a PRAGMA INTEGRITY_CHECK periodically. That
will help to find the problem as soon as it occurs.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
