Scott,

>> Actually it's simple to do, take a field that allows NULL fields,
>> change the system tables so that it no longer allows NULL fields,
>> neglect to check that there are no NULL fields in the database.

S> Oh, so purposely shoot yourself in the proverbial foot? That just
S> silly, why would anyone do that? I like to play in fields of the
S> RDB$SysTable, but even I'm not that stupid.

let's say you add a not null column to a table that you for whatever
reason believe is empty, and then forget about it. Or add the column
and do a suitable update, then got distracted and forget to commit.
:-)

>> First time you restore, when it finds a NULL it will explode faster
>> then a Ford Pinto rear-ended by a Mack sized truck.

S> Not so, everything else is restored, only the records that have errors
S> will not restore as would be with any RDBMS. Nothing has blown up,
S> the RDBMS has done exactly as you asked it: do not allow records in
S> this table that have field X as null.

First time gbak encounters such an error it will stop operation and
the rest of the backup file is unrestored.

>> 99% of the time a restore fails this is the reason why.

S> Therefore 99% of DB failures are do to user stupidity? That I can
S> believe. =P

I wouldn't call it supidity, rather lack of knowledge about the engine
operations. Restoring with the -R switch on the production database,
or using ambiguous connection strings in InterBase (not Firebird)
falls into the same category for me.

Ciao
--
Nando mailto:nandod@...