bcquality/microsoft/knowledge/performance/avoid-get-inside-loop-on-large-table.md
Jesper Schulz-Wedde a9f3c50863 Regenerate microsoft/knowledge from upstream BCApps instructions
The previous LLM-generated knowledge files contained factual
hallucinations. The most visible was the claim that `FindFirst` /
`FindLast` "forces a full-table scan" on an unfiltered record - it does
not; those APIs return a single row via the current key.

Other inaccuracies the audit found and fixed:

* `FindSet(true)` was described as "taking a LockTable". The correct
  upstream phrasing is that `FindSet(true)` sets
  `ReadIsolation::UpdLock` on the read. UpdLock and LockTable are
  related but distinct mechanisms.
* The list of production-scale tables had been invented beyond the
  upstream source (e.g. "Detailed Cust. Ledg. Entry") without a
  citation. The regenerated list matches the ten tables upstream lists
  with their P95 row counts.
* `SetLoadFields` guidance had been augmented with an extra mechanism
  claim ("the database resolves the filter using the index without
  hydrating the value") not present in upstream.

Approach: full regeneration of `microsoft/knowledge/` from the six
upstream BCApps Code Review instruction files, with Microsoft Learn /
the AL language reference as a secondary source. Every claim in every
regenerated file is anchored to a verbatim upstream quote (or a Learn
URL); the audit trail lives in artifacts/trace-<domain>.json on the
session workspace.

The PR #11 transaction/error-handling cluster is preserved verbatim:

* performance/understand-implicit-transaction-boundary.md
* performance/codeunit-run-as-atomic-sub-operation.{md,good.al,bad.al}
* performance/codeunit-run-requires-prior-commit-inside-transaction.{md,good.al,bad.al}
* performance/use-tryfunction-for-error-catching-not-rollback.{md,good.al,bad.al}
* performance/avoid-commit-inside-loops.{md,good.al,bad.al}
* security/commitbehavior-attribute-scopes-explicit-commits.{md,good.al,bad.al}
* testing/transactionmodel-attribute-governs-test-transactions.{md,good.al,bad.al}

These articles already cite Microsoft Learn and were carefully
cross-referenced; the regeneration skips their topics rather than
duplicating them.

File counts after regeneration:

  performance   35 .md  (5 preserved + 30 new)
  privacy       17 .md
  security      18 .md  (1 preserved + 17 new)
  style         33 .md
  testing        1 .md  (preserved)
  ui            19 .md
  upgrade       18 .md

Total 141 atomic knowledge files, each strictly one rule. All pass
.github/scripts/validate_frontmatter.py with 0 errors and 0 warnings.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-05-21 09:53:09 +02:00

1.7 KiB

bc-version domain keywords technologies countries application-area
all
performance
n-plus-one
get
findfirst
loop
inner-lookup
large-table
al
w1
all

Avoid Get / FindFirst inside a loop on a large inner table

Description

A Get or FindFirst against a different record inside a loop body produces one database round-trip per iteration — the classic N+1 pattern. Per the upstream guidance, "Flag when a Get()/FindFirst() is called inside a loop for each record — this creates N+1 database round-trips." The cost only matters when the inner table is meaningful: lookups against temporary tables, singleton setup tables, enum-mapping tables, permission objects, or Role IDs are bounded and safe. The pattern to catch is the inner lookup that hits a production-scale table for every outer row.

Best Practice

When the loop needs values from another record, lift the lookup out of the loop if the rows can be collected up front, or apply SetLoadFields so each inner read transfers only the columns the loop actually uses (see use-setloadfields-for-partial-records.md). When the inner record is small or bounded, leave the call site alone — the rule targets large-table inner lookups specifically.

See sample: avoid-get-inside-loop-on-large-table.good.al.

Anti Pattern

Iterating BOM lines and calling Item.Get(BOMLine."No.") per row to read a costing method, with no SetLoadFields on Item. Each iteration issues one query against Item (~800k rows) and pulls the entire row to read two fields. The fix is Item.SetLoadFields("Costing Method", "Standard Cost"); ahead of the loop — still N reads, but each one transfers only the needed columns.

See sample: avoid-get-inside-loop-on-large-table.bad.al.