Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +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

22
microsoft/knowledge/performance/understand-implicit-transaction-boundary.md Normal file
View file

@ -0,0 +1,22 @@
---
bc-version: [all]
domain: performance
keywords: [commit, transaction, implicit-commit, write-transaction, runtime, boundary]
technologies: [al]
countries: [w1]
application-area: [all]
---
# AL auto-commits when code execution completes
## Description
In AL, write transactions are managed by the runtime, not by the developer. When AL code begins executing from an entry point — an outermost trigger, a codeunit invoked via `Codeunit.Run`, a report, a page action — the runtime opens a write transaction on the first database write. When that execution completes without error, the runtime commits automatically; if that execution errors, uncommitted writes are rolled back. Explicit `Commit()` is not how write transactions are *started*; it is how a single execution is *split* into multiple transactions. Per the platform reference, "The Commit method separates write transactions in an AL code module."
## Best Practice
Default to no explicit `Commit()`. Let the runtime open and close the transaction around the execution. Reach for `Commit()` only when the execution has a real reason to persist partial progress — for example, a long batch that must release locks between checkpoints (see `avoid-commit-inside-loops.md`), or work that calls an external service and must persist the resulting handle before continuing with operations that may fail independently. If a stretch of work needs to either complete fully or have no effect, prefer `Codeunit.Run` over manual Commit choreography (see `codeunit-run-as-atomic-sub-operation.md`).
## Anti Pattern
Sprinkling `Commit()` defensively — at the end of a procedure, after every Modify, or "just to be safe" — reflects a SQL-style mental model that does not apply here. Every stray Commit shortens the rollback window: work before the Commit survives later errors the developer almost certainly intended to unwind. A Commit without a specific reason is a bug waiting to surface.