bcquality/microsoft/knowledge/performance/changecompany-in-loop-drops-caches.md
Jesper Schulz-Wedde 4f0a13a801
Promote knowledge for Microsoft review skills (#153)
Move canonical knowledge for Microsoft-owned review domains into the Microsoft layer and document the skill/knowledge co-location policy.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
Copilot-Session: 2a6ea875-d38e-4f30-aadb-0d606f9be231
2026-09-03 15:06:01 +02:00

1.3 KiB

bc-version domain keywords technologies countries application-area
all
performance
changecompany
loop
cache
multi-company
isolation
al
w1
all

Do not call ChangeCompany inside a per-row loop

Contributions welcome — open a PR to refine or extend this article.

Description

ChangeCompany retargets a record variable to another company's data and drops the in-memory caches bound to the previous company. Calling it once per row in a multi-company scan therefore pays a cache reset on every iteration, even when consecutive rows share a company. Agents treat ChangeCompany like a filter. It is an isolation switch.

Best Practice

Group work by company. Call ChangeCompany once per distinct company, then FindSet/Get that company's rows. If the record variable is reused afterward, call ChangeCompany() without a company name to redirect it back to the current company.

See sample: changecompany-in-loop-drops-caches.good.al.

Anti Pattern

repeat Rec.ChangeCompany(Buffer.Company); Rec.Get(Buffer."No."); until Buffer.Next() = 0 when Buffer is not ordered by company, or even when it is — if ChangeCompany still runs every row. The signal is ChangeCompany inside repeat/while keyed by a document line rather than by a company loop.

See sample: changecompany-in-loop-drops-caches.bad.al.