Hands high in the air, I haven't the foggiest, haven't used sqlite and don't write C++, so I'm a wast of time I guess?
From what you say, I note the following points:
1. It works fine for 3 or 4 days, so it can't be all bad.
2. I get the impression that this has happened several times, so what have you got to do to recover the database.
3. Silly to ask, but what does "SQL error: Database Disk Imaged Malformed" actually mean?
4. Is any database reorganisation going on or indexes being re-written during the running of your C++ program.
5. How many other users are there of this database?
6. How large is this database?
7. Why do I ask so many questions. [[simple, when you have a problem you get to ask a single question, but when providing answesr you get to ask several. This is why I try to supply answers rather than to have problems.]]
Quote:
|
From the Sqlite Wiki: This simple design is achieved by locking the entire database file at the beginning of a transaction.
|
Quote:
|
Several computer processes or threads may access the same database without problems. Several read accesses can be satisfied in parallel. A write access can only be satisfied if no other accesses are currently being serviced, otherwise the write access fails with an error code (or can automatically be retried until a configurable timeout expires). This concurrent access situation would change when dealing with temporary tables.
|
In my experience, and I don't know if Sqlite falls into this category, I have come across a number of small databases developed into systems and farmed out to multiple users only to suffer from frequent corruption of table indexes that needed to be rebuilt to get things up and working again. Causes of failure probably ranged from locking contention and people switching off PC's that seemed to be hung, lack of error handling and similar. Basically these databases were designed for the desktop, deployed as multi-user and proved not to be of industrial strength for the job in hand. Are indexes cached on remote systems and disenfranchised by periodic table reorgs, optimisations etc?
I ask all these questions because from the tone of your question, I feel your database is in production and just appears to be screwing up from time to time on a regular basis which you have identified as every three or four days, but I feel you recover it ok and don't have to re-build it, so it can't be totally catastrophic.
Same days of the week?
Same sort of time of day?
Fails at 10:30 in the morning or after lunch just when people are getting busy on the system?
Nothing to do with unclosed files causing a running out of available file handles every few days, down to a programming oversight?
Tell me more - your readers are intreagued - and someone doubtless has a good suggestion; hopefully I have made it already. Good Luck Ravi.
PAix
