Timeline for Rolling back a complete transaction
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 10, 2017 at 2:21 | comment | added | sfdcfox♦ | This solution will break bulk data loads, and should not be used. | |
| Aug 10, 2017 at 2:18 | vote | accept | SfdcBat | ||
| Aug 10, 2017 at 3:21 | |||||
| Aug 10, 2017 at 2:04 | comment | added | Santanu Boral | yes, that should be | |
| Aug 10, 2017 at 2:03 | comment | added | SfdcBat | I see your point. May be I did not mention that I do not want to update the foo record if its corresponding zoo record fails. I got an idea to use a validation rule on Foo__c itself which will prevent it from updating that specific record for which zoo cannot be created. With this I do not have to use Database.Insert method as well and Insert should be enough. | |
| Aug 10, 2017 at 1:56 | comment | added | Santanu Boral | According to your question you are not preventing updates on Foo__c record, you are mainly concerned about inserting Zoo__c record and displaying error message | |
| Aug 10, 2017 at 1:54 | comment | added | Santanu Boral | no it will not, your validation rule is on zoo__c. Or otherwise, you can insert master and detail in a single transaction based on externalid | |
| Aug 10, 2017 at 1:49 | comment | added | SfdcBat | Would this prevent that specific Foo__c record from updating? | |
| Aug 10, 2017 at 1:45 | history | answered | Santanu Boral | CC BY-SA 3.0 |