Dmitry Yemanov wrote:

>Then the entire restore should belong to a single transaction with almost
>everything restored before tables. And in the case of broken procedure BLR
>we'll get a restore failure without any data in the database. Is this what
>you suggest?
>
>
>
>

I would like to see a careful, thoughtful design, something that would
allow any backup that ran to completion to be restored. This will
certainly require the ability to disable various constraints when
necessary. It certainly would require the ability to disable foreign
key checking on specific foreign keys (a very good thing in its own
right). It would also mean that procedure would not be activated during
the load process.

It is important to metadata updates performed during DDL statements be
completely validated, but this shouldn't apply to direct system table
updates. In the long run, I'd like to deprecate direct update of system
tables altogether, but that will take a long, long time. In the
meantime, I'd like to strong discourage them. I would also like to make
explicitly illegal any reference to tables within a transaction in which
the table's system tables have been modified. And make all DDL
statements effectively auto-commit. This increases the difficulty of
in-place metadata update by script, so I'd like Firebird to implement
the "upgrade <object>" commands.

Adding more code isn't the answer -- removing code is. Simplify the
sucker.

But to answer your question, if you backup a broken procedure, after a
restore, you still have a broken procedure. Isn't that what backup and
restore are supposed to do?

The bottom line is that I consider unrestorable backups to be a
near-criminal offense.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376