DML Limits are reset when?

Question

I have a scenario where I need to update 500,000 Accounts in production to change their Record Type, but I want to avoid writing a Batch class for one-time use. In addition, using DataLoader would require an extreme amount of documentation (don't ask, its a validated org). For whatever reason, code is easer to be validated than using DataLoader.

In our scenario, the Account Trigger updates on average 3,000 records for each 200 Accounts.

Could I run an Execute Anonymous code block that updates 10,000 accounts in a single DML statement? Since the update in the Execute Anonymous block will already hit the 10,000 limit, will the first attempt to update a (for example) Contact fail because it will be the 10,0001st update? Or do the DML limits start over for the first block of 200 trigger records?

Answer 1

Nothing about the trigger context is going to reset the DML Rows limit. If updating 200 Account records consumes on average 3000 DML Rows, then on average you are going to be able to update 666 Account records per transaction in Execute Anonymous (9990 rows). If your 15:1 ratio is very stable, you can reliably use a number near or above 600. If you have high variance, you will want to drop that number lower to reduce limit. If you got 666 Account records through every time it would still take 750 transactions, if you had to drop it to an average of 550 you'd be up to 900 transactions. Even if you are able to complete an average of 6 transactions per minute without any errors, it will take you 2 - 2.5 hours.

If you're weighing that against less than 3 hours of documentation, it sounds like you're doomed to an exercise in tedium either way. However, if you can write the batch in 3 hours, you're way better off. In addition to not dying of boredom, you will have a much lower chance of human error.

Answer 2

In addition to @AdrianLarson's answer, let me point out a commonly-overlooked issue with execute anonymous and triggers

Many triggers are written with static Boolean variables to guard against recursion, for example with this recipe or this SFDC Knowledge Article

But if your execute anonymous does an update on 201+ records in a single transaction (and by definition, execute anonymous is a single transaction), what will happen is this:

• SFDC will deliver records 1-200 to the trigger
• The trigger will do its work, setting the static Boolean variable to prevent trigger recursion
• SFDC will deliver records 201-400 to the trigger
• The trigger will think it is recursing and DO NOTHING. This will be repeated for records 401...600, 601..800, ...

The comments to the recipe point out this flaw and provide the workaround - keep maps of ids in a static variable to use for recurse check, not a single all-or-nothing boolean static variable

Data Loader doesn't have this problem as each set of 200 records is a separate transaction.

So, in summary, use Execute Anonymously with care, perhaps by executing it successively on no more than 200 records.