Greg Miller wrote:
Liz Steel wrote:

You say that I shouldn't get a corrupt database when I pull the power, but I am consistently getting this. I am using SQLite version 2.8.9 using the C++ interface running on Windows XP Home. Is there anything I can do to stop this happening?

If you have an IDE hard drive that's caching writes, there's not much the OS and database software can do to prevent corruption on power loss. It's possible to avoid this with tagged queueing, but most drives don't support that. The FreeBSD folks tried to solve this by turning off write caching by default. Unfortunately, this hurt performance so much they had to turn it back on and just recommend SCSI drives for important data.

I looked into this some and came back with different information. Who can tell me what is right?

From what I am told, most IDE drives do signal the OS when the data
reaches the platter.  I'm also told that the Linux fsync() call does
not return until it gets that signal.  The Windows FlushFileBuffers(),
on the other hand, does not wait for the data to get to platter.  So
on a windows system, there is a brief moment of vulnerability where
a power loss can lose data.  But on Linux, that window of vulnerability
is zero.

The above is how IDE drives are *suppose* to work.  There is wide-
spread suspicion that many cheap IDE drives do not implement the
protocol correctly.  If your have one of those broken IDE disks,
all bets are off.

I am also told that the Linux IDE driver is broken with respect to
media errors.  If the disk drive has a media error, Linux does not
take appropriate corrective action, nor does it alert the user-space
code.  I don't know how true this is or if it is really a problem.
(How common are media errors?)

Regardless of the situation, though, the window of vulnerability
during which a power loss might cause database corruption is small.
And Liz is reporting that she can reproduce the corruption
consistently.  So perhaps her trouble have a different cause.

D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to