You need to sign in to do that
Don't have an account?
Chris Voge 9
Strange behavior with triggers
Hello,
Been researching an issue with duplicate inserts of records.
Below, I posted some log entries for a BeforeInsert and AfterInsert for a trigger.
The question I have is should the number records in the BeforeInsert (represented
by the word "new" ) be equal to the number of records in the AfterInsert (represented
by the id's) ?
I think this may be part of my issue. Just looking for direction.
Let me know if you need more information.
07:25:16.0 (146648)|CODE_UNIT_STARTED|[EXTERNAL]|01qU0000000DJN6|LeadsTrigger on Leads trigger event BeforeInsert for [new, new, new, new, new, new, new, new, new, new, new] 11 inserts
*
* misc logs
*
07:25:18.471 (3127040361)|CODE_UNIT_FINISHED|LeadsTrigger on Leads trigger event BeforeInsert for [new, new, new, new, new, new, new, new, new, new, new] 11 inserts
*
*
* validations
*
*
*
07:25:19.593 (3593202511)|CODE_UNIT_STARTED|[EXTERNAL]|01qU0000000DJN6|LeadsTrigger on Leads trigger event AfterInsert for [a0E0P00000pYNMQ, a0E0P00000pYNMR, a0E0P00000pYNMT, a0E0P00000pYNMU, a0E0P00000pYNMV, a0E0P00000pYNMW, a0E0P00000pYNMX, a0E0P00000pYNMY, a0E0P00000pYNMZ, a0E0P00000pYNMa] 10 id's
*
* misc logs
*
07:25:19.593 (3596467452)|CODE_UNIT_FINISHED|LeadsTrigger on Leads trigger event AfterInsert for [a0E0P00000pYNMQ, a0E0P00000pYNMR, a0E0P00000pYNMT, a0E0P00000pYNMU, a0E0P00000pYNMV, a0E0P00000pYNMW, a0E0P00000pYNMX, a0E0P00000pYNMY, a0E0P00000pYNMZ, a0E0P00000pYNMa] 10 id's
Thanks, Chris
Been researching an issue with duplicate inserts of records.
Below, I posted some log entries for a BeforeInsert and AfterInsert for a trigger.
The question I have is should the number records in the BeforeInsert (represented
by the word "new" ) be equal to the number of records in the AfterInsert (represented
by the id's) ?
I think this may be part of my issue. Just looking for direction.
Let me know if you need more information.
07:25:16.0 (146648)|CODE_UNIT_STARTED|[EXTERNAL]|01qU0000000DJN6|LeadsTrigger on Leads trigger event BeforeInsert for [new, new, new, new, new, new, new, new, new, new, new] 11 inserts
*
* misc logs
*
07:25:18.471 (3127040361)|CODE_UNIT_FINISHED|LeadsTrigger on Leads trigger event BeforeInsert for [new, new, new, new, new, new, new, new, new, new, new] 11 inserts
*
*
* validations
*
*
*
07:25:19.593 (3593202511)|CODE_UNIT_STARTED|[EXTERNAL]|01qU0000000DJN6|LeadsTrigger on Leads trigger event AfterInsert for [a0E0P00000pYNMQ, a0E0P00000pYNMR, a0E0P00000pYNMT, a0E0P00000pYNMU, a0E0P00000pYNMV, a0E0P00000pYNMW, a0E0P00000pYNMX, a0E0P00000pYNMY, a0E0P00000pYNMZ, a0E0P00000pYNMa] 10 id's
*
* misc logs
*
07:25:19.593 (3596467452)|CODE_UNIT_FINISHED|LeadsTrigger on Leads trigger event AfterInsert for [a0E0P00000pYNMQ, a0E0P00000pYNMR, a0E0P00000pYNMT, a0E0P00000pYNMU, a0E0P00000pYNMV, a0E0P00000pYNMW, a0E0P00000pYNMX, a0E0P00000pYNMY, a0E0P00000pYNMZ, a0E0P00000pYNMa] 10 id's
Thanks, Chris
I just cannot see what is triggering the second attempt at saving the data.
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_bulk_exceptions.htm
When errors occur because of a bulk DML call that originates from the SOAP API with default settings, or if the allOrNone parameter of a Database DML method was specified as false, the runtime engine attempts at least a partial save:
(1) During the first attempt, the runtime engine processes all records. Any record that generates an error due to issues such as validation rules or unique index violations is set aside.
(2) If there were errors during the first attempt, the runtime engine makes a second attempt that includes only those records that did not generate errors. All records that didn’t generate an error during the first attempt are processed, and if any record generates an error (perhaps because of race conditions) it is also set aside.
(3) If there were additional errors during the second attempt, the runtime engine makes a third and final attempt which includes only those records that didn’t generate errors during the first and second attempts. If any record generates an error, the entire operation fails with the error message, “Too many batch retries in the presence of Apex triggers and partial failures.”
In our code, we use static variables to prevent triggers from executing multiple times.
When the second attempt at saving the data occurs, the systems sees the variables are
set and bypasses a bunch of code.
Besides failed validation rules, what are some other reasons where a second or third attempt
to save the datais made ?
Any ideas ?
Thanks, Chris