SF-PD2 Performance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Increase the DML statement limit in the Apex class.

  Why it's wrong here

  Governor limits are fixed and cannot be changed by the developer. The platform enforces these limits to maintain system stability and prevent resource-intensive code from affecting other tenants. The only way to resolve this error is to optimize the code to perform fewer DML operations per transaction.

• ✓

  Refactor the code to collect records in a List and perform one DML.

  Why this is correct

  Bulkification is the core design pattern for Salesforce development. Moving DML outside the loop ensures that only one DML statement is used regardless of the number of records, which completely eliminates the 'Too many DML statements' error and makes the code scalable and highly performant.

• ✗

  Move the logic to a @future method to allow more DML.

  Why it's wrong here

  While @future methods execute in a separate transaction, they still have their own DML limits. This approach simply shifts the problem rather than solving it. Furthermore, it adds unnecessary complexity and latency by introducing asynchronous processing for logic that should be handled synchronously in the trigger.

• ✗

  Use the Database.update() method with allOrNone set to false.

  Why it's wrong here

  Using Database.update() does not change the number of DML statements consumed. If the code is still calling update inside a loop, it will hit the same limit regardless of the allOrNone setting. Bulkification is the only way to avoid the limit exception in this scenario.