Lester Caine wrote;

> Simply by keeping track of the total_cost_of_sales and the number sold.

> You do not need to visit any records in TableB other than the one being

> inserted. In fact, only the on_insert trigger is required, and will be

> triggered when an order is committed. You should not normally be

> deleting records in table B, but if you are, then the totals need to be

> subtracted rather than added, and if you need to update an order,

> normally I would cancel the existing order, and add a new one, so you

> have a record of the changes via records in TableB with a cancelled flag

> attached.

Thank you Lester I didn't think it that way . It sounds good.

While updating an order ; a trigger which will subtrack the old_value and
then
add the new_value will work I think.

I want to make it clear that ; when we are inserting/updating/deleting a
record from table B
if we use triggers for table B ( using only the results from the record
which caused the trigger to fire) ,
to update fields in table A, there will be no lock conflict.
Also this is nothing to do with transactions autocommit property . Is it
right ?

Again , in this trigger if I visit some other records in table C or table D,
Will there be a lock conflict ?
( not using records from Table B but gathering information from other tables
)


Regards,

Metin Gonen



---
avast! Antivirus: Giden mesaj temiz.
Virus Veritabani (VPS): 0525-5, 25.06.2005
Test zamani: 26.06.2005 13:54:26
avast! - copyright (c) 1988-2004 ALWIL Software.
http://www.avast.com