I tried changing the names a bit to make it easier for me to understand:

create table MILAN ( BABUSKOV INTEGER );
SET TERM ^ ;
CREATE TRIGGER NEW_BU2 FOR MILAN ACTIVE BEFORE UPDATE POSITION 0 AS
BEGIN
select MILAN.BABUSKOV from MILAN
where old.BABUSKOV = MILAN.BABUSKOV
into new.BABUSKOV;
END^
SET TERM ; ^
Commit;
INSERT INTO MILAN (BABUSKOV) VALUES (1);
update MILAN set BABUSKOV = 2;
select * from MILAN;

Though I must admit I originally thought the trigger would use
where old.BABUSKOV = new.BABUSKOV.

Doing things like this (at least if complicating it a bit further) could
be quite useful if you want to prevent users from changing any values
and at the same time hide the source code from them (if you deleted the
source code, then even if someone managed to reverse engineer the code
it wouldn't be immediately obvious what it did).

And I do admit, you're good at confusing people and proved that it is
still possible to write ambiguous queries in Firebird ;o)

Set

Milan Babuskov wrote:

> Who says we don't want FB to be strict with ambiguity:
>
> create table new ( old INTEGER );
> SET TERM ^ ;
> CREATE TRIGGER NEW_BU1 FOR NEW ACTIVE BEFORE UPDATE POSITION 0 AS
> BEGIN
> select new.old from new where old.old = new.old
> into new.old;
> END^
> SET TERM ; ^
>
> INSERT INTO NEW (OLD) VALUES (1);
> update new set old = 2;
> select * from NEW;
>
> Can you guess what this query would return? 1, 2 or NULL? ;)
>
> P.S. This is only for fun. I doubt anyone would name their tables NEW or
> OLD.