At 07:58 AM 5/8/2004, Geoff Worboys wrote:

> >>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?

Well, they're certainly not features. There is some disagreement
in my family about adding constraints to a populated database. I
think the system should check that the constraint is consistent
with the state of the database before the constraint is added. My
beloved thinks that's unreasonable - slow etc.

>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.

Gbak doesn't handle reflexive views very well, if I remember. If
you have the script, send it along.

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

Yes, it's a physical backup, not a logical backup.

>Either
>the backup/restore should have worked regardless, or the engine
>should have prevented the DDL scripts from creating incompatible
>structures (or both).

Yes.

Regards,


Ann