I would like to track more than 20 fields on my custom objects, so built a logic almost same as What is the best workaround for the 20 field history tracking cap?. This works most of the time if you are using update commands. But if you are using update commands on Database class like Database.update(sObjects, false) which allows partial updates, how can we know which objects are successfully updated and which objects are not? Is there any way to retrieve the addError that was added on a sObject in trigger?
Add a comment
|
1 Answer
Your question is a bit of an X-Y problem, but basically, you can't determine from within the trigger context if errors have been added to a record or not. You can only determine the errors from the calling context (e.g. the API or upper-level context that called Database.update(records, false)). However, it doesn't matter. The history records you create during your trigger will automatically be rolled back in the case of a failed update (the system creates a save point, then rolls back if any errors occur before trying again).
-
Thanks for the answer...But I don't want to revert all my changes right...Assume I am passing two records to Database.update(<List with 2 records>, false)...One record has error in trigger, so we use addError to prevent updating that record..but other record doesn't have any error, so it gets updated successfully...so in my logic after the trigger, I want to track changes made on that successful record and insert to my custom history tracking record...how would I know which record has error and which record doesnot?– RamCommented May 24, 2018 at 18:39
-
@Ram Are you expecting the field-tracking object to give errors? That's kind of defeating the purpose, isn't it? If you're using code just like was written in the question/answer you linked, you don't need to do anything special, as I said, because the system takes care of it for you.– sfdcfox ♦Commented May 24, 2018 at 19:23
-
No, I don't want to track changes for error records either... In after trigger, our custom code verifies if the field has changed and creates a record to custom tracking history table... For example, Name has changed from ABC to XYZ, and price is changed from 10$ to 20$ and in before trigger we are adding error to this record as price is greater than 15$... In after trigger, as the name field is changed, we will create record in custom history tracking as we can't see that error is aded to this record, right? Sorry if I am not being clear enough....– RamCommented May 24, 2018 at 23:27
-
@Ram You've missed the point; when the record fails to validate, the field history record will never be created because the changes from the trigger will be rolled back. No changes will persist for the errored record. You may want to try it for yourself to see how it works. I've already tested this.– sfdcfox ♦Commented May 24, 2018 at 23:33