Three related concerns, each proven by executable tests rather than recall. They were extracted from a real defect that shipped through a six-reviewer panel undetected, which is the admission test passing on behavior rather than on theory. owning-table-must-delete-dependents-in-ondelete AL has no cascading delete. What makes it missable is an asymmetry: the platform DOES keep references correct on rename via TableRelation, so a developer who learns that and generalizes it to delete ships orphans. Also notes the permission trap (delete rights needed on the dependent table, not just the parent). validate-table-relation-false-suppresses-rename-propagation The non-obvious half. The property name implies input validation only, but disabling it also switches off rename propagation. Verified against a parent renamed once while a child held three fields: a normal relation (follows), the same relation with validation disabled (does NOT follow), and a field with no relation at all (does not follow) — the third being the control that proves the test can detect a non-propagating field. xrec-is-a-before-image-only-in-some-triggers Corrects both the naive belief that xRec is always the previous record and the folk rule that it 'only works from a page'. The behavior is per-trigger: a genuine before-image in OnRename and OnDelete regardless of driver, a mirror of Rec in OnInsert/OnModify when driven from code, and a real before-image in those two only when a page drove the write. That last asymmetry is why an OnModify comparison against xRec passes manual page testing and silently no-ops in a job queue. Targets /community per CONTRIBUTING — general BC knowledge, not fork-specific. Frontmatter validator clean; Test-ReviewFixtures passes (32 cases, 16 leaves).
2.4 KiB
| bc-version | domain | keywords | technologies | countries | application-area | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
data-modeling |
|
|
|
|
xRec is a before-image in OnRename and OnDelete, but mirrors Rec in OnInsert and OnModify from code
Description
xRec is widely believed to be "the previous record" inside every table trigger, and — in reaction to that — is often dismissed with the folk rule "xRec only works from a page, never from code". Both are wrong, and the second is wrong in the place it matters most.
The behaviour is per-trigger. In OnRename and OnDelete, xRec is a genuine before-image regardless of what drove the write. In OnInsert and OnModify, a code-driven write leaves xRec mirroring Rec — there is no before-image at all — while a page-driven write does supply one.
That combination produces a defect that is unusually hard to catch. A comparison such as if Rec.Status <> xRec.Status then inside OnModify works when a tester clicks through a page, and silently never fires when the same code path runs from a job queue, a batch routine, or an API call. It fails as a no-op, not as an error.
The OnRename case is the useful half: because xRec there holds the previous primary key even from code, it is the one place a hand-written key fix-up is reliable. Note that in OnRename only the key differs between Rec and xRec — non-key field values are identical on both sides.
See also validate-table-relation-false-suppresses-rename-propagation.md, which describes when such a hand-written OnRename fix-up is required.
Best Practice
Use xRec for the previous key in OnRename, and for the record being removed in OnDelete. In OnModify, obtain the before-image by re-reading the stored row rather than trusting xRec, so the logic behaves identically whether a page, a job queue or an API drove the write.
See sample: xrec-is-a-before-image-only-in-some-triggers.good.al.
Anti Pattern
Comparing Rec against xRec inside OnModify (or OnInsert) to detect a change. From code the two are equal, so the branch is dead and whatever it guards never happens.
Detection signal: any read of xRec inside OnModify or OnInsert. Treat "but it works when I test it on the page" as confirmation of the defect rather than a refutation.
See sample: xrec-is-a-before-image-only-in-some-triggers.bad.al.