>>If corruption occurs due to bugs, the bugs need to be fixed.

...

> Quite. And does this also include "logical" corruption, that
> is, when the database gets into some inconsistant state at a
> high level? It seems that there are a few known issues of
> this sort. Are they to be considered as simply bugs?

I would guess so. Either because a function does not operate
properly or because an action should not be permitted.

I found that I could create databases that upset gbak. Create
the database with scripts that cause no errors and operate
as I expect. Do a gbak backup and restore and bang! - corrupt
database. I suspect that its because I used a few things that
work - but are probably not recommended because of the various
dependencies that they introduce. Attempts to isolate the
problem down to a specific issue were not successful.

I have not tested against FB 1.5, but I know the problem still
existed in early FB 1.0 releases.

A backup and restore should be fool-proof. What you put in
should be what you get back out again - even if that means
that you carry bad data/structure over at the same time. If
a user wants validation of a database that should be a separate
process.

I have not studied the plans for nbackup - but I am hoping that
it avoids some of the pitfalls in the design of gbak.

NOTE: I dont really want to start a long conversation about
gbak - I've resolved my own issues in that regard by building
DBak. This is just my example of "logical" corruption. Either
the backup/restore should have worked regardless, or the engine
should have prevented the DDL scripts from creating incompatible
structures (or both).

--
Geoff Worboys
Telesis Computing