> I get experience in this problem:
>
> Check this table:
>
> CREATE TABLE "TEST"
> (
> "A" INTEGER NOT NULL,
> "B" INTEGER,
> "C" VARCHAR(10) CHARACTER SET WIN1250,
> "X" INTEGER
> );
>
> INSERT INTO TEST (A, B, C, X) VALUES (1, 1, 'a', NULL);
> INSERT INTO TEST (A, B, C, X) VALUES (2, NULL, NULL, NULL);
> INSERT INTO TEST (A, B, C, X) VALUES (3, NULL, NULL, NULL);
> INSERT INTO TEST (A, B, C, X) VALUES (4, NULL, NULL, NULL);
> INSERT INTO TEST (A, B, C, X) VALUES (5, NULL, NULL, NULL);
>
> Ok.
>
> If I open this table in IBOConsole/IBOQuery, or in IBExpert, then it
> show the records/fields correct (as is).
>
> But when I modify the B,C,X fields to NOT NULL in IBxpert...
>
> update RDB$RELATION_FIELDS set
> RDB$NULL_FLAG = 1
> where (RDB$FIELD_NAME = 'B') and
> (RDB$RELATION_NAME = 'TEST')
>
> ... and then I reload the table, it is changed.
>
> The IBExpert/FibPlus shows the correct field contents, NULL-s.
>
> The IBX/IBO/IBOConsole shows the default field values, integers as 0,
> strings as '', etc.
>
> Why ?

I believe it has to do with IBO detecting that the column is NOT NULL able
and so I represent the value in the buffer and ignore the null indicator.
This is because older versions of InterBase would not populate the null
indicator on not null columns. Perhaps now later versions do actually bring
back the full null indicator value even if the column is not null and IBO
should respect that. It simply is a matter of how the buffer structures are
interpreted. It would be very easy to change. I'll add this to my list of
things to review.

I do hope you will realize this is not a very good idea to do. If you ever
make a column NOT NULL able then you should also take responsibility and
provide values for all those columns that are null at the same time.
Otherwise, you could find your self unable to restore a backup with the data
in this condition.

Regards,
Jason Wharton
www.ibobjects.com