Jim: I think you're hitting it right. I cannot use just an AFTER DELETE because the record is gone and I cannot track which OppID I was working on. And you're right, it does seem like it puts some kind of "lock" on the row BEFORE the delete, although it seems strange that a (select(max)) would violate a lock...
So what I did was split my procedure into a BEFORE and an AFTER. On the before, I simply selected the OppID into a variable, and then on the AFTER I would do the calculations. Seemed like a good idea. but I might have uncovered a bug in the latest 9.5 build in that whatever stored procedure name I select it assigns it to both the before and after. I cannot get it to give me 2 separate procedures... So I've submitted the bug report this morning. Karen In a message dated 7/30/2012 10:27:38 AM Central Daylight Time, [email protected] writes: > Karen, > Is this a BEFORE DELETE or AFTER DELETE Trigger? > Conflicts may arise if it is define as a BEFORE DELETE Trigger as to the > best of my knowledge the record action is still pending at that point. > Your 2nd and 3rd selects are accessing "OppActivity" table which is being > held by the internal read only cursor used to define the trigger action. > I believe that an AFTER DELETE Trigger will not have the conflicts. > > >
