- Home
- Technical Library
- Boards
- Cookbook
- Code Share
- Blogs
- Partners
-
More
-
Services
- Training & Certification
- Support
-
Galleries
- Force.com Sites Gallery
- Chatter Challenge Entries
-
Other Web Sites
- Salesforce.com
- Database.com
- AppExchange
- CRM Community
-
Add Recipe
App Distribution (13)
Bundle logic, interface and services for distribution.
App Logic (52)
The Apex programming language, workflow and formulas for logic.
Collaboration (7)
The Salesforce Chatter collaboration platform.
Database (29)
Data persistence, reporting and analytics.
Integration (57)
Web Service APIs and toolkits for integration.
Security (22)
Platform, application and data security.
Tools (17)
Force.com tooling
User Interface (38)
Visualforce MVC and metadata-drive user interfaces.
Web Sites (13)
Public web sites and apps with optional user registration and login.
Beta Feedback
Recipes by Category
App Distribution (13)
Bundle logic, interface and services for distribution.
App Logic (52)
The Apex programming language, workflow and formulas for logic.
Collaboration (7)
The Salesforce Chatter collaboration platform.
Database (29)
Data persistence, reporting and analytics.
Integration (57)
Web Service APIs and toolkits for integration.
Security (22)
Platform, application and data security.
Tools (17)
Force.com tooling
User Interface (38)
Visualforce MVC and metadata-drive user interfaces.
Web Sites (13)
Public web sites and apps with optional user registration and login.
Cookbook Home » Controlling Recursive Triggers
Share
X
Vote to Verify a Recipe
Verifying a recipe is a way to give feedback to others and broaden your own understanding of the capabilities on Force.com. When you verify a recipe, please make sure the code runs, and the functionality solves the articulated problem as expected.
Please make sure:- All the necessary pieces are mentioned
- You have tested the recipe in practice
- Have sent any suggestions for improvements to the author
Please Log in to verify a recipe
You have voted to verify this recipe.
© Copyright 2000-2011 salesforce.com, inc. Web-based Customer Relationship Management (CRM) Software-as-a-Service (SaaS).
All rights reserved Various trademarks held by their respective owners.
All rights reserved Various trademarks held by their respective owners.
Salesforce.com, inc. The Landmark @ One Market, Suite 300, San Francisco, CA, 94105, United States
General Enquiries: 415-901-7000 | Fax: 415-901-7040 | Sales: 1-800-no-software
General Enquiries: 415-901-7000 | Fax: 415-901-7040 | Sales: 1-800-no-software

Recipe Activity - Please Log in to write a comment
To get around the problem stated by jochen5478, I actually started using static Maps to track which records had already been processed and only processing them if they aren't in the Map(s). This is certainly not a completely safe solution but at least records in the "Subsequent" batches are being processed. The problem with this approach is that if you really have a lot of records, you can very quickly reach scripting and/or storage limits.
I agree with jochen5478 this pattern is not bulk safe at all and by implication there does not appear to be a workable solution to handling recursive triggers for large amounts of data. You can demonstrate the problem using the sames code posted in this solution and using the dataloader to insert more than 200 tasks. In my case I tried adding in 300 tasks, expecting to see 300 follow up tasks created, but only 199 follow up tasks were created. This is due to the fact that the trigger processes records in batches of 200 so after the first 200 are processed the flag hasAlreadyCreatedFollowupTasks is set. Each subsequent batch of 200 records that the trigger processes is in the same process where the hasAlreadyCreatedFollowupTasks is still set to true and as a result no follow up tasks are created for these batches. This is a major weakness with platform development and should really be looked into resolving.
There is a problem with handling batches. If batch size is over 100 the batch is splited into parts of 100 or lower. For each subbatch trigger code is executed but stays in the same context (so governer limits count for both subbatches). But the static variable is not reset! By this behaviour you may have run your trigger code for the first 100 records but not for the last 100 records of the batch!
This problem is barely documented by salesforce but I think this is a big issue for developers need to cope with recrusive triggers!
Sorry about that - I've fixed the repeating code.
actually this work around doesn't work properly in a test method context because the static survives across "DML contexts". So if you do another DML Operation on the same object in the same test method it will think that the trigger has already been invoked.
Even worse trigger SOQL count is NOT reset by test.startTest as documented.
I just noticed that as well too. All three code blocks are the same.
The trigger example code and the test example code are the same as the class example code.