Hello,
This example shows ref integ exe order is important:

let table t1, table t2 as:

t1 :== (f0 int PK, f1 int, f2 int)
t2 :== (f3 int PK, f4 int)

where

t1.f1 references t2 on delete [RESTRICTED]
t1.f2 references t2 on delete CASCADE

rows are

t1={(1,2,2)}
t2={(2,3)}

if you post

delete from t2 where f3=2

the transaction does not fail, and deletes both rows.
So, in this example, FB applies cascade, and then restricted.
FB does not executes restricted first, in wich case the transaction must fail
due to ref integ violation t1.f1 ref t2.


The questions are:

If constraints exe order is important ...

What order follows FB?
Is always the same fixed order, or FB computes some kind of backtracking in
order to found an exe order of constraint that makes transaction does not
fail?

Until now, we know (guess) through examples, that FB does not construct any
kind of backtracking (because exe time is very low) and constraints order are
cascade, restricted. In order to know the rest of constraints exe order, we
should make a lot of examples, and still remains the question "is the exe
order fixed or calculated in a per operation basis?".

Of course, we does not found doc on this topic. Still is possible to
investigate source. Do you recommend to do this?

Regards.
Campos, Dalto, Allende

> At 12:20 AM 12/9/2002 -0300, IBUNC wrote:
>
> >We are investigating on execution order of the triggers, referential
> >integrity actions and constraints in face of a statement posted to the
> >server.
>

> "Ann W. Harrison" wrote:
> Constraints
> are executed next in an arbitrary order.
>

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