Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-07 09:56:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Transaction and error handling in BC AL - new knowledge articles

Browse source
This commit is contained in:
Volodymyr Dvernytskyi 2026-04-23 20:58:02 +03:00
parent 7dd3f4777d
commit 4ce7d816cc
19 changed files with 415 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

8
microsoft/knowledge/performance/avoid-commit-inside-loops.md
View file

@ -1,7 +1,7 @@
---
bc-version: [all]
domain: performance
keywords: [commit, loop, transaction, lock]
keywords: [commit, loop, transaction, lock, checkpoint, codeunit-run]
technologies: [al]
countries: [w1]
application-area: [all]
@ -13,11 +13,13 @@ application-area: [all]
## Description
Commit ends the current transaction. Calling it inside a loop produces one transaction per iteration and loses the ability to roll back the whole operation atomically. It also interferes with the platform's ability to batch write operations. The original motivation — releasing locks during a long batch — is better served by splitting the batch into explicit checkpoints that each process a bounded number of rows.
Commit ends the current write transaction. Calling it inside a per-row loop produces one transaction per iteration and loses the ability to roll back the whole operation atomically; it also interferes with the platform's ability to batch write operations. Most loops need no explicit Commit at all — AL auto-commits the enclosing code module on successful completion (see `understand-implicit-transaction-boundary.md`). When the batch is too large for one transaction, the fix is not a per-row Commit but bounded checkpoints that each process N rows.
## Best Practice
If the batch is large enough that a single transaction is untenable, process it in checkpoints driven by an outer loop that each time picks up the next N rows. Commit once per checkpoint at a clearly defined safe boundary, not inside the per-row loop.
If the batch is large enough that a single transaction is untenable, process it in checkpoints driven by an outer loop that each time picks up the next N rows. Commit once per checkpoint at a clearly defined safe boundary, not inside the per-row loop. Wrapping each chunk in `Codeunit.Run` gives the same effect with native rollback on failure — see `codeunit-run-as-atomic-sub-operation.md`.
See sample: `avoid-commit-inside-loops.good.al`.
## Anti Pattern