> I've had a look in the archives but I cant seem to find
> anything on this (I could of sworn that I'd seen it somewhere before).

Yep, it has occurred before(to me many times)

>
> We've just had a customer who can no longer restore their
> database backups because someone has added a column with a
> not null constraint to one of the existing tables. This then
> filled the existing rows with a null value in the added
> column... So at restore time it tries to insert null data
> into a not null field.

Is the customer waiting to restore this DB? Ie, they're restoring from a
disaster, and the only copy they have is this backup?
The reason I ask is, if the live database is ok, set a value in the field
with nulls, and then backups and restores will run ok.

`update table set field = 0 where field is null;`

As long as it doesn't break business rules/processing, that'll make every
backup and restore from here on ok.

> I guess my question is this: Why does firebird allow a column
> to be added with a not null constraint without specifying a
> default value? When adding this column it destroys the
> database integrity by clearly violating one of the constraints.

I seem to recall this issue being fixed. What version of Firebird are you
running?

N.