Results 1 to 2 of 2

Thread: Mutating table

  1. #1
    Join Date
    Dec 2003

    Unanswered: Mutating table

    So, we've employed a pretty elaborate scheme for getting around the Mutating table error, where we buffer rows in a PL/SQL table inside the BEFORE ROW trigger, and then process each of those rows in an AFTER STATEMENT trigger.

    It works, but initial coding is usually strained by the fact that anytime you UPDATE, INSERT or DELETE from the AFTER STATEMENT trigger, you re-enter the BEFORE ROW trigger where the rows were buffered initially. So you have to write the appropriate control structures which circumvent the code specifically meant for the MUTATING TABLE error, but you still process your business rules.

    So, I was thinking this morning, what if we moved this "MUTATING TABLE AVOIDANCE" code into an INSTEAD OF trigger, and updated via a VIEW. I goofed around with some code and it seems to work ok. So, I'm turning to ya'll now to see if there's some fatal, obvious flaw that I'm overlooking. I can't think of why it would be any different, other than the fact that you'd always need to perform DML via the view, whereas now you can go directly against the table.


  2. #2
    Join Date
    Sep 2002
    Provided Answers: 1
    I don't know of any issue - but...

    If you are going to stop users from performing DML on the table, why not just create an API package rather than a view and INSTEAD OF triggers?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts