I would disagree with you at this point Paul, any alter or drop of a
table / view or constraint of any kind has the risk that old programs
may stop working. In my case, the field was flagged as NOT NULL
because the table was originally designed wrong and it was part of the
Primary Key. Because of the complexity of the relationship between
this table and others, triggers had to be added to "update" dependant
tables after any changes, which really hurt performance.

If you keep adding fields, then you will quickly build a system where
no programmer or report writer will know which field they should be
using without reading a mountain of documentation. The fields in our
table have naming conventions, for example ValidFrom and ValidTo
appear in many transaction tables. If you wanted to make a change to
ValidFrom and added a new field ValidFrom2 or something, then you will
confuse everyone.

That said, you do make a valid point about how database changes are
not to be taken lightly. All "dependancies" (not just internal tables,
but any programs, reports or libraries) need to be checked and fixed
before release.

I have investigated Martijn's suggestion, and I believe this would
work. Disclaimer: I haven't tried it.

-- Flag Field as a NOT NULL Field

UPDATE RDB$RELATION_FIELDS
SET RDB$NULL_FLAG = 1
WHERE RDB$RELATIONNAME = [Table Name]
AND RDB$FIELD_NAME = [Field Name]

-- Make sure no value in field is null

UPDATE [Table Name]
SET [FieldName] = [Default Value]
WHERE [FieldName] IS NULL