How about this scenario:

Start trans 1 (snapshot or read committed).
Start trans 2 (snapshot or read committed).

Trans 1:
Update master record (so trigger cascased changes to all child
records)

Trans 2:
Insert child record refering to original value in master (which is
still visible in this trans context)
Commit.

Trans 1:
commit.

RI broken.

Of course if the master table is very static it's not a practical
issue. Just a situation where things could turn very sour in the
future if you forget the master table is 'read-only'.

We need commit triggers! (hmm, could you rollback in a after-commit
trigger???)

John

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> Referential integrity doesn't get broken by deleting

the "children" of the

> referenced key. You place the action rule (ON DELETE CASCADE) on

the

> children to signal that, when the parent key gets deleted, the

referencing

> rows in the "child" table must be deleted also.
>
> It is done by triggers. A trigger is a special kind of stored

procedure

> that runs each time the specified operation (DELETE, UPDATE,

INSERT)

> happens to a row on the table. It runs only for that row.