With the introduction of Autonomous Transactions this is no longer entirely true. If you call an autonomous transaction procedure, it is executed in a separate transaction context. This gives you the ability to probe the mutating table without inducing the error. A good explanation can be found in Tom Kyte's Export One-on-one Oracle book in the chapter on Autonomous Transactions.
HTH
Tony Aponte
-----Original Message-----
From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 9:24 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Complex Integrity Checking
no matter what you do, if you access table A inside a trigger on table A,
oracle will give you mutating table error. What you could (and I really mean
you have to consider your business logic here) is go ahead and insert the
rows with a temp flag. As soon as you commit, fire up a procedure that will
do the scan on the table and delete appropriate rows which have the temp
status.
BTW how big is this table? What is the frequency of inserts and updates?
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
