Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 22:56:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Adopt 11 community rules into custom always-on layer

Browse source 
Promotes rules that are already published in community/ to custom/knowledge/,
so they load at every session start instead of only on keyword relevance.
Each file carries extends: pointing back to its community source.

Passed Immanuel's four-test Categorical Imperative validation on 2026-08-07.
This commit is contained in:
Michael Dieringer 2026-08-07 08:04:12 +02:00
parent b79b90c4ec
commit d4e351f333
11 changed files with 231 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
custom/knowledge/error-handling/table-event-subscriber-rolls-back-whole-batch.md Normal file
View file

@ -0,0 +1,21 @@
---
bc-version: [all]
domain: error-handling
keywords: [table-events, oninsert, onmodify, ondelete, transaction, rollback, commit, batch, subscriber]
technologies: [al]
countries: [w1]
application-area: [all]
extends: community/error-handling/table-event-subscriber-rolls-back-whole-batch.md
---
# A Throw In A Table-Event Subscriber Rolls Back The Whole Batch
> Contributions welcome — open a PR to refine or extend this article.
## Description
Table-trigger event subscribers (`OnAfterInsertEvent`, `OnAfterModifyEvent`, `OnAfterDeleteEvent`, and their `OnBefore` counterparts) execute synchronously inside the transaction of the write that fired them. Because AL runs on a single implicit transaction with no per-record savepoint, an error raised in such a subscriber rolls back **all work since the last `COMMIT`** — not just the record that triggered it. In a batch loop with no intermediate `COMMIT`s, a single failing record discards the entire batch. The intuition that subscriber validation fails only the current record is wrong on the BC platform.
## Best Practice
Decide the failure granularity deliberately. If a batch must continue past individual failures, do not throw from the table-event subscriber — collect the error (for example via `ErrorInfo`/collectible errors) and let the loop continue, or isolate each record's work behind a `Codeunit.Run` / `if Codeunit.Run() then` boundary so its failure rolls back only that record. Insert intermediate `COMMIT`s only with full awareness of the durability trade-off.
## Anti Pattern
Putting `Error`/`TestField`/`FieldError` validation inside a table-event subscriber and assuming it rejects just the offending record during bulk processing. The first failure unwinds every uncommitted record in the run, turning a one-row data problem into a whole-batch rollback.