Helen Borrie wrote:

> Yes, it is dictated by both the standard and Boolean logic. If you would
> prefer to simplify *your* logic, so that new.field <> old.field always
> gives true when not (new.field = old.field) then make the columns in
> question non-nullable and enforce a default value via a Before Insert trigger.

This is was not an option in my case. I needed the null state as well.

> "Inconvenient" is strange. After all, you only write the trigger once.

I meant that doing this kind of simple check is more complicated than it
would seem at first. Needlessly i dare say.

> [...]
> Just remember that if new.field and old.field are both null, you won't get
> True on an equivalence comparison either...

So we are back at the beginning :)

> I think you'll learn to know and love null, all the same. <g>

Oh i love nulls.. i just don't like how they are evaluated. It would be
logical if null be considered a valueless state, not unknown. Or
whatever, as long as - [field with a value] <> null = true.
I really can not think of any use for unknown state or a boolean
condition that can evaluate to unknown. I guess it's my limited mind :))

Anyway i got my answer and i guess i will just have to live with it.


BR,
Lauri
(Lets make a new standard! - the Bill Gates way of solving problems :)