Hello, Louis!

> Try the following with IB Expert V1.0.2.92:
>
> 1. Create a new table T1 with a first column called ID as an

INTEGER and

> checking the 'NOT NULL' check box. The DDL it executes is correct.
> 2. Create a PK constraint on the ID column by using the constraints

tab and

> adding the prim. key
> 3. Insert a record with ID = 1 using the data tab and editing

inside the

> grid. Commit the changes
>
> So far so good
>
> 4. Create a new table T2 with a first column called ID as an

INTEGER and

> checking the 'NOT NULL' check box.
> 5. Create a PK constraint on the ID column by using the constraints

tab and

> adding the prim. key
> 6. Add a nullable column FK of type INTEGER to table T2 using the

fields tab

> 7. insert a row (ID,FK) values (1,null) and commit changes
> 8. Add a foreign key on column FK table T2 to reference table

T1.ID. The

> foreign key is created no problem as the column is nullable.
>
> So far so good
>
> 9. Use the fields tab and double - click on the FK column to edit

it. Check

> the NOT NULL check box. If you look at the DDL it executes, you see

the

> following:
>
> update rdb$relation_fields set rdb$null_flag = 1 where

(rdb$field_name =

> 'FK') and (rdb$relation_name = 'T2')
>
> The result of this action is a FK column value of 0 in table T2,

with a

> foreign key referencing table T1 ID and WITH NO ID COLUMN VALUE OF

0....!!!!!!

Really???? I tried so and so and I still have NULL value in T2.FK.
I don't know how do you get 0 in FK but I can guarantee that
this isn't IBExpert initiative and you can't get 0 if you didn't
update
your FK field with value of 0.

> In my opinion, this is illegal...!!!

What is illegal???? I agree with you: the value of 0 is illegal.
But I can't reproduce this situation and even my logic tells me that
it's impossible to have 0 in FK after executing your "script" step-by-
step.

> I think the problem is with the DDL that is executed as part of the

NOT

> NULL making excercise.

You aren't right.

> I don't know much about IB internals, but what it
> seems like is that the trigger that fires on a column add does not

fire to

> ensure ref. integrity due to the process being short-circuited by

IB

> Expert.
> As far as I know, you should drop the FK column and re-add it with
> a NOT NULL specifier and then add the FKey.

This will work if you have no dependencies on FK column.
But if you have many SP or triggers, for example, that use this
column, you can't drop fk column without recompiling all SPs and
triggers with commented references to this column.
So IBExpert allows you to avoid many changes in your SPs and
triggers if you just want to change NOT NULL specifier.
Of course, each developer should understand that these kinds
of modifications (I mean modifications of IB system tables)
aren't standard things and should remember about care.

> This is one example of dangerous things that IB Expert does /

allows. There

> are a couple of other examples like this.

Yes, IBExpert allows many non-standard things, but it doesn't make
force to
do these things. It allows but YOU come to a decision...
And each developer should know, that there is no way to change NOT
NULL
specifier for a field using standard DDL-statements.

> It also allowed me to change a domain definition from VARCHAR(60)

to DATE

> while I had a column using the domain with populated values!!!

And what???
IBExpert also allows you to open table editor for RDB$PAGES,
go to Data tab and modify/delete records in/from this table. And your
database will be corrupted...
You can also edit any system table using IBExpert. It allows this...
You can execute any statement using SQL Editor, even if this
statement will delete all records from RDB$DEPENDENCIES, for
example...
Does it mean, that IBE is dangerous tool?

My hex-editor allows me to open any exe, ddl or gdb and change any
byte or sequence of bytes. Does it mean that my hex-editor is very
dangerous tool??

> Here is the DDL:
>
> update RDB$FIELDS set
> RDB$FIELD_TYPE = 35,
> RDB$FIELD_LENGTH = 8,
> RDB$CHARACTER_LENGTH = NULL,
> RDB$CHARACTER_SET_ID = NULL,
> RDB$COLLATION_ID = NULL
> where RDB$FIELD_NAME = 'EMAIL'
>
> AFAIK this is also pretty dangerous. Scary stuff....

Just don't make such strange modifications and all will be ok.
And don't forget that these "dangerous" features were implemented
after users requests.
Of course, we can disable them but is this solution acceptable???

> It's very nice to be able to make changes not normally allowed, but

it

> screws your database in the process. Our policy is now..: ALL

METADATA

> CHANGES DONE BY SCRIPT ONLY.

--
Best regards,
Alexander Khvastunov

IBExpert - The Most Expert for InterBase and FireBird
http://www.ibexpert.com