Am 30.06.2006 um 00:01 schrieb [EMAIL PROTECTED]:
I have never yet found anything useful by analyzing a corrupt
database file. Generally, the only way to fix this kind of problem
is come up with a reproducible test case.
Unfortunately, that may prove difficult, if not impossible :(
Anyway, thanks for your quick reply...
P.S.: the sqlite version used at the customer site was 3.3.4
What OS? How did you compile SQLite (what compile-time options
are turned on?) What run-time options are using using
(auto-vacuum, non-standard page size, etc)? How large are the
database files when you first notice the corruption. What
was the program doing at the time the corruption appeared?
- Mac OS X (not sure what the exact version at the client side was -
10.3 or 10.4).
- configure options are: --enable-threadsafe --disable-shared --
enable-static CFLAGS="-g -O2 -Wno-long-double"
- we are building with a custom Xcode project (in this case using
gcc-3.3 to get backward compatibility with 10.3). We build as a
static link library (universal binary PowerPC & Intel). Compile time
defines are:
OS_UNIX=1 SQLITE_OMIT_CURSOR THREADSAFE=1 HAVE_USLEEP=1
SQLITE_THREAD_OVERRIDE_LOCK=-1 TEMP_STORE=1 NDEBUG
- we don't use any special runtime options, the only special thing we
do when opening the database is to use "PRAGMA short_column_names=OFF"
- Our last schema update did run a VACUUM and did run some ALTER
TABLE ADD COLUMN statements afterwards. (not sure whether this is
relevant)
- The database file was about 16 MB when the corruption was noticed.
- I have no idea what the program was doing when the corruption
appeared. It's a multithreaded server application, thus it's hard to
say what was going on even if I knew the exact time when the
corruption occured :(
Sorry, this is probably not a whole lot of useful information.
Assuming nobody (except for sqlite) touched the database or journal
files, any idea what could be other reasons that may lead to a
database corruption?
Thanks,
</jum>
