Helen Borrie wrote:

> [-cut-]
> The problems you encountered have to do with the
> (inadvisable) use of meaningful data as foreign keys and the consequent
> problems stemming therefrom. Your setup will inevitably break
> relationships that really shouldn't be broken, by cascading whenever a user
> fixes a typo or even accidentally touches the spacebar.
> [-cut-]

Your puritanism is misplaced in this case. The example script was to
prove a point.
I have my reasons for this kind of setup.

> It's a question of designing your keys so that (a) they will cascade in the
> right sequence and (b) they won't cascade when they are not intended to. A
> lot of the time, you can do it with the auto RI triggers, with some careful
> attention to the downstream relationships.

I agree. My point was, that there should be some obvious way of making
the right sequence happen. Dropping and re-creating is... a hack.
Also the error message is vague in this case. Maybe a warning could be
included at the end of the message when there are more events to be
triggered.

> This kind of question isn't one I would consider worth debating...

Why is that? I'm not trying to waste your time or be a smart-ass.
The reason i first posted, was to find out, if a feature could be
included to control the FK order in some not-so-cryptic manner
(currently the order of creation).

Related feature idea:
Option to ask a list of all events triggered by an update, insert or
delete, in order of firing. And possibly the ability to modify the order.


BR,
Lauri