mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
e00ef8ad94
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).
70 lines
1.8 KiB
AL
70 lines
1.8 KiB
AL
table 50120 "Source Document"
|
|
{
|
|
fields
|
|
{
|
|
field(1; "No."; Code[20])
|
|
{
|
|
DataClassification = CustomerContent;
|
|
}
|
|
}
|
|
|
|
keys
|
|
{
|
|
key(PK; "No.")
|
|
{
|
|
Clustered = true;
|
|
}
|
|
}
|
|
|
|
// "Source Key" below cannot declare a TableRelation, so the platform cannot
|
|
// repoint it. The owning table carries the relationship by hand.
|
|
trigger OnRename()
|
|
var
|
|
DocumentLink: Record "Document Link";
|
|
begin
|
|
// In OnRename, xRec holds the PREVIOUS primary key while Rec holds the new
|
|
// one — the one trigger where that is true regardless of what drove the rename.
|
|
DocumentLink.SetRange("Source Key", MakeSourceKey(xRec."No."));
|
|
if DocumentLink.FindSet(true) then
|
|
repeat
|
|
DocumentLink."Source Key" := MakeSourceKey(Rec."No.");
|
|
DocumentLink.Modify(true);
|
|
until DocumentLink.Next() = 0;
|
|
end;
|
|
|
|
local procedure MakeSourceKey(DocumentNo: Code[20]): Code[50]
|
|
begin
|
|
exit(StrSubstNo('DOC|%1', DocumentNo));
|
|
end;
|
|
}
|
|
|
|
table 50121 "Document Link"
|
|
{
|
|
fields
|
|
{
|
|
field(1; "Entry No."; Integer)
|
|
{
|
|
DataClassification = CustomerContent;
|
|
}
|
|
// Default ValidateTableRelation: the platform repoints this on rename.
|
|
field(2; "Document No."; Code[20])
|
|
{
|
|
DataClassification = CustomerContent;
|
|
TableRelation = "Source Document"."No.";
|
|
}
|
|
// Composite value — no TableRelation can express it, so the parent's
|
|
// OnRename above maintains it explicitly.
|
|
field(3; "Source Key"; Code[50])
|
|
{
|
|
DataClassification = CustomerContent;
|
|
}
|
|
}
|
|
|
|
keys
|
|
{
|
|
key(PK; "Entry No.")
|
|
{
|
|
Clustered = true;
|
|
}
|
|
}
|
|
}
|