This is pretty slick!  

So taking it a step farther, suppose I set this up so that my uses can delete an Invoice, I would then have the invoice triggers deleting the lineitems.  Now suppose I want my users to be able to delete a customer..... so the triggers on the customers table will take care of deleting the invoices, in which the invoice triggers will then take care of the deleting the line items?

Seems like this would work, but when I delete a customer, wont the transaction that is started in the invoices trigger clash with the transaction that is started in the customers trigger?

If so, then would the solution be to handle the transaction/commit/rollback stuff on the client side (ie: the transaction code would wrap around the initial Delete operation on the client side, no transaction code would then be in the triggers)

Just wondering.

Dale

Dale,

<< Seems like this would work, but when I delete a customer, wont the
transaction that is started in the invoices trigger clash with the
transaction that is started in the customers trigger? >>

Yes, but you can use the INTRANSACTION function to determine if you're
already in a transaction:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=INTRANSACTION

The main thing is making sure that the parent modification starts a
transaction for all possible affected tables.  If you can't determine that,
just start the transaction on the entire database in each instance.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Yes, but you can use the INTRANSACTION function to determine if you're
already in a transaction:>>

This is great, but I still don't get how to handle the After Delete Trigger? I suppose that, in Dale's example, the After Delete Trigger on the customer table should commit the transaction. How can the invoice and line tables After Delete Triggers, that fire first, determine that they should not commit the transaction? Or should they?

thanks for any help...

Walter

Walter,

<< This is great, but I still don't get how to handle the After Delete
Trigger? I suppose that, in Dale's example, the After Delete Trigger on the
customer table should commit the transaction. How can the invoice and line
tables After Delete Triggers, that fire first, determine that they should
not commit the transaction? Or should they? >>

You can use a temporary table as a repository for session-specific variables
that span multiple triggers.  You can use a separate column for each table
to indicate which table started the transaction.

It's a bit convoluted, but it does work until we get nested transactions
done in EDB, which is part of the hold-up on the cascading updates/deletes,
also.

--
Tim Young
Elevate Software
www.elevatesoft.com