Is this on windows? Any errors in the Eventlogs to the tune "Oooopsie -- accidentally threw away your data instead of writing it to disk"? Windows does this quite commonly under some circumstances. MicroSoft created the bug in NT 4 and has been unable to locate or fix it since -- though there is no problem producing an error message about 50% of the time it happens.
> -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Yannick Duch?ne > Sent: Tuesday, 2 February, 2016 14:58 > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] Bug: Successfully committed transaction rolled back > after power failure > > On Thu, 28 Jan 2016 14:55:28 +0000 > Simon Slavin <slavins at bigfraud.org> wrote: > > > > > On 28 Jan 2016, at 1:38pm, Bernard McNeill <bm.email01 at gmail.com> wrote: > > > > > === > > > Like the user reading ?saving OK? and throwing away the > > > Post-It with the original information > > > === > > > > > > This is exactly my concern. > > > The user throwing away the Post-It is entirely reasonable if he sees a > > > message like that. > > > > > > Do you happen to know if Linux/Debian (which I think uses a > journalling > > > filesystem) carries this risk? > > > > The problem is not at the software level. Various operating systems and > file systems are correctly programmed with regard to waiting for write > commands to complete. I don't know specifically about Debian but Linux > has a good reputation for such things, and anyone who bothers to write a > journalling file system would understand how to do things properly. > > > > The problem is at the hardware level. Standard disk drives (including > their motherboard if they have one, and their firmware) are designed for > speed, not integrity. The assumption is that you will be using them to > play games or write your CV in Word, not to keep vital data. So they are > set up, using their default jumper positions, to lie. In order to keep > their computer running as fast as possible, instead of > > > > 1) receive write command > > 2) perform write command > > 3) read that bit of disk to confirm the change > > 4) if not, bring SMART system into play and try writing it somewhere > else > > 5) if succeed, tell the computer "I wrote that and it worked." > > 6) otherwise tell the computer "I wrote that and it failed." > > > > they do this > > > > 1) receive write command > > 2) tell the computer "I wrote that and it worked." > > 3) perform write command > > 4) read that bit of disk to confirm the change > > 5) if not, bring SMART system into play and try writing it somewhere > else > > Coincidence. I just had a funny incident; may be it's related. > > I just modified a program so that it create fours triggers in a database. > I ran the program, then got an error from APSW (the program uses Python) > complaining about an I/O or disk error. This frightened me a bit, but I > though this may be due to SQLiteBrowser opened on the same DB, which I > forget to close and I closed just after I started the program, which was > subject to the I/O issue. I open the DB and can see only two of the four > triggers, two missing. So I delete the DB and regenerate it three times, > without error messages, but still two triggers missing. That's only at the > fourth repetition the four triggers was all there. > > The SMART data indicates zero reallocated sectors. > > In the SMART utility, I noticed there is an hardware cache, which I > disabled, in case of and thinking about ?lying devices? I remembered from > this message. > > This is frightening to me, as I got an error message the first time only, > but not the other times while something wrong seems to have happened too. > Also, I could notice something was missing in the DB (even when generated > without an error notification), because it was about something I was > precisely looking at, at that moment; if it had been about some rows > missing in any table, I would have not noticed it. > > Hardware failure? OS failure? Software failure? Can't tell for sure?? > > > > -- > Yannick Duch?ne > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
