At 09:37 PM 09-11-02 +0000, you wrote:

>using Marathon, I have unchecked the NOT NULL property of column XY.

Erk. As Fb/IB doesn't provide any SQL syntax for removing a NOT NULL
constraint, Marathon must have attempted to do this by updating the system
tables.

>If I list the table structure, now XY appears as a nullable (not NOT
>NULL) column.
>
>However, if I try to input a NULL value, I get an error message,
>exactly as FB retained the NOT NULL property for the column.

It looks as if Marathon has only gone part of the way toward clearing out
every link that was implemented by the DB engine to enforce the NOT NULL
constraint. The engine would have prevented it from deleting the
RDB$DEPENDENCIES records, for example, if those dependencies still existed...

>Is there a safe and easy way to fix things ?

First, it would be a good idea to inspect the metadata using a different
tool, e.g. the database browser of IB_SQL, to check whether the metadata
are actually damaged; or whether it is some settings in Marathon causing
the metadata to be misreported.

>I have a large number of dependencies on that column ...

If you have damaged metadata, I hope you have a backup.

When you go to do this exercise again, make sure that you remove all of the
dependencies *before* you attempt to remove the NOT NULL constraint on this
particular table.column. This means closing all transactions and
performing a database shutdown; then, with exclusive access as sysdba or
the owner of the database *and* of all the inter-dependent objects,
dropping all foreign key constraints and compiled objects (triggers, SPs)
that depend on it.

After that, you *might* be able to use a tool to delete the
constraint. Just make sure that you hang on to your backup...

heLen