You need to sign in to do that
Don't have an account?
Swerz
Recursion of triggers
Hi Guys,
I am analysing the impact of something called 'critical updates' from SFDC for my organisation. It mentions that some of our triggers might be having unnecaessary recursions. They define recursion as:
"A recursion is a situation in which a part of your custom logic (such as a roll-up summary field or Apex trigger) causes Salesforce to execute the logic twice when saving a record, often resulting in undesirable behavior."
Do you have any idea how can I verify that a trigger is having recursion? Can I monitor it?
Thanks,
S
Swerz,
One place to start could be to write some testmethods to cover your triggers and insert into the trigger some debug messages. These would then appear in the 'run test' output. You could also try using the System Log to see whats going in when certain things happen when the user does something in the UI.
I would have thought that your triggers would be ok until you reach you governor limits - if this hasn't occured then there's no real problem.
In some cases 'controlled' recursion is part of the functionality required by a system so it isn't always a no-no to have recursion per-say.
R.
Hi Swerz,
I would like to refer you to Spring'09 release and some key updates provided by Salesforce in relation "recursive trigger" scenarios.
I am providing possible scenarios below which had been identified as a sure-shot cases of potential recursion in trigger/ duplicate firing of triggers -
Suppose you have a master and child object.
1. Master object has a trigger A (after insert, update, after undelete)
2. Master object has a Workflow Rule R1 (which creates a Task if the condition is met)
3. Trigger A in turn makes an update on Child object.
4. Master Object has a ROLL UP Summary field on Child. So if step #3 (trigger) does update child, its roll up would reflect in Master.
What was happening as a result of above case, if when roll up field values changes on Master, it gets treated as an update to the Master and causes TRIGGER A and Workflow Rule R1 to fire again.
Not only above scenario, there can even be cases where you have a Trigger B, defined on Child object (after update, after delete) which in turn makes update to Master object.
What Salesforce did from Spring'09 onwards, that did applied some fixes in platform to detect these recursive conditions (parent updating child and child again updating parent) and includes checks to avoid firing of TRIGGER, Workflow Rule on Parent twice.
Now you need to verify in your Org if such cases do exist, and verify that with new fixes that Salesforce has rolled out in Spring'09 onwards, these functionalities continue to work correctly & do not malfunction.
You can refer to Spring'09 release documentation for details. I am providing a snapshot of the documentation below for your quick reference -
"
Regards
Satgur
Hi Satgur,
thanks for the input.
I am actually analysing the exact same scenario for my org. Looking for such structures. But its a bit tricky, finding such processes. That's why I wanted to know if I can monitor a trigger recurring and can analyse why that is happening.
I guess Richie's sloution is what would do the trick. thanks Richie. Let me get back if I could get it done :).
thanks