Bull219 uttered:
Dear all,
I am developping a freeware which uses SQLite. One of my beta testers
informed me about an issue he had: with his DB, following the query which is
sent to the DB, I have the error in the subject of this email. I did some
testing, and when I succeeded in reproducing the error just by doing a
VACUUM. I also reproducing the error by doing a "select * FROM table". What
is strange is that if I do a select with a specific WHERE condition so that
few rows are returned, no error is raised.
You'll get the error doing a VACUUM because VACUUM iterates over all the
records in the database, as does the "select * FROM table" iterate over
all the records in that table. The constrained select query obviously is
not hitting the region of corruption.
Could you please help me as I need to have a stable DB before releasing the
final version of my freeware?
That you can reproduce the problem indicates this is unlikely to be a
hardware issue. Can you reproduce the test case reliably and consistently?
Things to check:
- Multiple processes accessing the database file. SQLite will arbitrate
access using a well defined locking protocol. If a process does not
respect this protocol, or locking is defective (NFS perhaps) then
corruption can result from two processes updating the file.
- Check for crashes and/or removal of the rollback journal.
- Check that your program is not corrupting memory. This would more likely
manifest itself in a SIGSEGV, but you're best checking.
Things to tell us to offer better advice:
- SQLite version
- OS platform (Windows, Linux, UNIX etc.)
- Filesystem in use (native, NFS SMB etc.)
- Language used to access SQLite, plus info on the language SQLite
wrapper.
- How to reproduce the corruption.
Thank you very much in advance,
Best regards,
Bull
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
