>
> I want to do something like, when i insert or update a stock item, i

want to

> update the products and some other fields. so i wrote this:
>
> ... snip
>
> So, would it be better if i write a procedure that do the whole thing
> instead of these "cascading" triggers?
>
> ... snip
>
> Oh, and other question, i don´t know if i should ask it here on in a C#
> forum, but, i m using a transaction in my C# code, and using a

rollback() if

> it fails, if i do a rollback() in my C# code, it is going to rollback
> everything my procedure and triggers did isnt it? or should i code the
> transaction inside the procedure?

Procedures are inside transactions not outside like in MSSQL etc. You
can not rollback or commit a transaction inside a stored procedure or
trigger.

Assuming that rollback in C# does the obvious thing and asks Firebird
to rollback, then any action done within your transaction is undone
(including anything that was done implicitly by a stored procedure or
trigger).

Also, if an exception is raised and not handled, the current operation
is undone. So if you update a field, and your after update trigger
causes some problem such as violating a unique constraint in another
table, the entire update operation will be undone. If the update
operation was triggered within a stored procedure, and the exception
is not handled, all the work done by the stored procedure is undone.
Pretty simple really.

The decision as to whether your logic goes in a procedure or trigger,
well that depends on whether it should be possible to affect
MOV_EST_ITEM without causing these changes to propagate. If not, then
use the trigger.

Adam