bcquality/microsoft/knowledge/performance/pass-false-to-insert-when-trigger-not-needed.md
Jesper Schulz-Wedde b6da405376 Improve partner onboarding and documentation navigation
Lead with a complete plugin quick start and add task-oriented usage, troubleshooting, customization, and contribution guides. Preserve the broader plugin framing, correct conflicting contract guidance, support Agents folder reviews, and align repository validation. Convert existing sample references to clickable links without changing knowledge rules.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-09-09 17:25:29 +02:00

1.7 KiB

bc-version domain keywords technologies countries application-area
all
performance
insert
modify
delete
trigger
run-trigger
write-parameters
al
w1
all

Pass false to Insert/Modify/Delete when the table triggers do not need to fire

Description

Insert(true), Modify(true), and Delete(true) run the table's OnInsert/OnModify/OnDelete trigger; the (false) form skips it. Per the upstream guidance, the trigger form should be used "only when needed" — every row whose write fires a trigger pays that cost, even when the trigger has nothing useful to add for the current call site. For tight bulk write paths the difference compounds linearly with row count.

Best Practice

Reach for the (false) form when the calling code already enforces the invariants the trigger would, or when the trigger is empty for the current table/extension. Use (true) when the trigger does work the caller depends on (number-series allocation, validation, cascading writes). Decide per call, not by code style: a default of "always true" makes bulk writes pay for triggers they did not need, and a default of "always false" silently skips validation the trigger was put there to enforce.

See sample: pass-false-to-insert-when-trigger-not-needed.good.al.

Anti Pattern

Looping over thousands of rows and calling Modify(true) on each, when the table's OnModify trigger does nothing relevant for the operation. The trigger cost is paid per row; the user-visible behavior is identical to the (false) form. The mirror is using (false) for an operation that depends on trigger-side defaulting and silently producing rows that fail downstream validation.