Hi Ann,

Ann W. Harrison wrote:

>Which leads to the old question and answer" Q. What is the difference
>between theory and practice? A. In theory, there is none.
>
>

Ok, I see. It's understandable of course that there may be slight bugs
or things that cause corruption, in spite of the theory. But as long as
the theory is indeed that normally, the database _can't_ get corrupted,
then I know at least that any corruption that does occur ought to be
reported as a bug of some sort. This is different from Paradox for
instance (with which we used to work several years ago), where
corruption is an entirely "normal" part of life, that happens routinely
practically every time there's a power failure, or if the application
gets closed abruptly, etc.

>However, both InterBase 6 and Firebird 1.0x have gone a long way toward
>fixing corruptions that were common in InterBase 5.6. The most common
>corruption for InterBase 5.6 was any database that got to be longer than
>4GB. The insert pointer for the database file wrapped around and
>InterBase wrote new pages over the database header and the oldest
>database pages. That was bad.
>
>

Yes.

>Firebird 1.0 fixed two other significant problems that were common
>causes of corruption on Windows systems. The default on Windows changed
>to forced write. Unlike *nix systems, Windows does not flush it's page
>cache until the file closes. Unless forced write is enabled, no changes
>to a Windows database go to disk until the server shuts down. That's a
>disaster waiting to happen. The SuperServer on Windows formerly opened
>the database for shared write. It now uses exclusive write / shared
>read mode. That keeps the server from opening a single file twice under
>two different names.
>
>

I see.

>>Anyway, I have again got a DB corruption on a customer's PC, and so I'd
>>like to figure out what it's due to: is it a bug, or is there something
>>I can do to avoid it happening?
>>
>>I'm currently using IB 6.0.1.0, on Win 98.
>>
>>
>
>And you almost certainly suffered from having committed changes that
>were not written to disk because forced write is not the default for
>InterBase 6.
>
>

Ok, well I guess I'll check, though I'm practically sure forced writes
is on.

>>The machine was then shutdown (abnormally I presume, because there's no
>>trace of any clean shutdown in the log), and restarted (as evidenced by
>>the fact that at 9:00, the gardian was restarted):
>>
>>
>
>As Alex said, the reports you described don't indicate terrible
>corruption and you can probably just backup and restore the database -
>changing the state of forced writes - and continue.
>
>Let me explain a bit about some of the "horrible" looking errors,
>particularly the "orphaned" errors. Even with forced write enabled, a
>hard shutdown of a firebird server will sometimes result in "orphans".
> An orphan is a piece of storage that has been removed from a free
>space list, but not used.
>
>

Thanks for the explanation. I see, so "orphans" aren't really a problem,
they're just wasted space, right?

I'll check the database and make sure forced writes is on, and I'll
write back.

Thanks for your reply,
Jonathan Neve.


[Non-text portions of this message have been removed]