Hi,

The problem that Claudio described - the original (as designed) behaviour is
different from its current behaviour. Creating a before insert trigger that
inserts itself should not result in two records. As in: if you create BI
triggers, the insert itself should be gone and you should handle the insert
yourself.

As for the 'solution': create a fake join

If the behaviour is designed that triggers are a substitute for the actual
insert, there should not be a fake join - I don't want to work around bugs,
I would rather see the bug fixed :)

So, what is the designed and expected behaviour, and what is the current
behaviour and are these two the same?

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

>What problem is there to fix?
> > If "a" is the PK of T, you'll get a duplicate value
> > exception: the default
> > action took place, then the trigger tried to insert, too.
> > Since both are
> > using the value of "a" unmodified, they clash on the PK's index:
> >
> > SQL> insert into v values(0);
> > Statement failed, SQLCODE = -803
> > violation of PRIMARY or UNIQUE KEY constraint "INTEG_2" on table "T"
> >
> > There's no solution, you should do a fake join to force your
>
> Will this problem get fixed in FB?

[Non-text portions of this message have been removed]