--- In firebird-support@yahoogroups.com, "lobolo2000" <lobolo2000@...>
wrote:

>
> > It doesn't matter. The delete of the master and the cascading
> > deletes of the children are a single operation and succeed or
> > fail together. They can be executed in either order, since the
> > sequence of the operation should not be visible outside of
> > the operation.
>
> This is what I'd expect from referential integrity.
>
> > changing that behavior will be a major undertaking.
>
> I am no expert on database engine internals, but some research on this
> topic yielded the following excerpt from the Informix Guide to SQL
> that highlights a similar case where a tradeoff seems to have been
> made:
> "Important:
> You cannot define a DELETE trigger event on a table if the table
> defines a referential constraint with ON DELETE CASCADE."
>

Well that is real useful if you plan to audit delete actions isn't it.
Sounds to me like an implementation limitation of Informix.

The important thing to note, and the point I think I have been unable
to explain clearly is this:

It is impossible to end up with a record in the detail table without a
corresponding record in the master table with Firebird's
implementation. If you don't let it delete the detail (for whatever
reason), it will refuse to delete the master.

Adam