Ann W. Harrison wrote:

>First, there's the new backup in V2, which will happily restore a
>logically or physically corrupt database. That's probably the answer
>most people will use. For gbak, we could set up a mode where the last
>stage of the backup is a full restore to a temporary file that would be
>deleted when the "backup" finishes. A better solution, which is being
>implemented in steps, is to provide switches that disable checks on
>logical consistency - don't build indexes, don't perform constraint
>checks, ignore primary and foreign key constraints etc. Whenever we add
>a new check for logical consistency we need to add the ability for gbak
>to turn it off.
>
>Regards,
>
>
>Ann
>
>

Ann,

I think that a switch to ignore consitencies errors will be good.

But what about don't let the errors happen ?

If I add a new collumn that has a "not null" constraint, a default value
should be supplied by the user.

Just like a create unique index, it's not possible to create it if the
column has duplicates, this approach won't make the database more
consistent ?

The only time when I got a unrestorable backup was because I added a new
column with a not null constraint, and forgot to do an "update to some
value" in the next step, or I changed the rdb$null_flag by hand, can't
remember why... Anyway was my fault to not adjust my data to the new
rule, but will be good if the engine help me not to forgot about it.

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.1 - Release Date: 04/03/2005