This is above my head but could you Project the row you want to Delete to a Temp Table and reference it?
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.
