Thanks for your reply.

I did another test, just to make sure.
1) Create a test table
create table test (id int, nm varchar(12));

2) insert some values
insert into test (nm) values('test1');
insert into test values(2, 'test2');

3) change id's column def
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1
WHERE RDB$FIELD_NAME = 'ID' AND RDB$RELATION_NAME = 'TEST';

4) select a table
select * from test (via flamerobin)
result :

ID NM
[null] test1
2 test2

From those test, I think :
1) Firebird didn't raise an error when set null column into not null column (so I have to be more careful in the future)

2) return set shows null value when it is null. This is different from my first case when return set shows 0 for null value. So I guess what happened to my first case didn't come because I changed column definition from null to not null, it is still a mystery.

Thanks and regard,
Sugiarto

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 02:26 PM 9/05/2012, you wrote:
> >Thanks for your replay.
> >
> >If you see null with ibexpert, how come this data can be store in Firebird, since ddl for this column not allow for null value? Could it be a bug in Firebird?
>
> It was stored at some point before the column was changed to NOT NULL. When you do that change, the engine does NOT alter existing data. Thus, you must always make sure that you correct the data *before* you make that change.
>
>
> >Another strange results when issued this statement
> >
> >SELECT * FROM M_INT_FRM a
> >where a.id_div_lc is null
> >
> >It will returns 3 result (via flamerobin).
>
> Why is it strange? You have already established that you have nulls stored in this column, from its previous life as nullable.
>
> ./heLen
>