Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
bcquality/microsoft/knowledge/events/changecompany-runs-triggers-in-the-calling-company.md
Jesper Schulz-Wedde 4e33ca87e2 knowledge(upgrade): upgrade code must not use ChangeCompany 
Addresses ADO bug 651092. Upgrade and feature data update code must run in the
context of the company being upgraded; ChangeCompany leaves triggers, events and
upgrade tags in the calling company and races the target company's own upgrade.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-10-02 10:11:49 +02:00

6.4 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
events
changecompany
cross-company
runtrigger
trigger-event
subscriber
onafterinsertevent
insert
startsession
multi-company
al
w1
all

ChangeCompany leaves triggers and trigger-event subscribers running in the calling company

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

Description

ChangeCompany redirects the data access of one record variable to another company's table. Execution context does not move with it: Microsoft Learn states that triggers still run in the current company, not in the company passed to ChangeCompany. Code that knows this usually reaches for Insert(false) and copies the trigger's work by hand from the target company's setup. That closes only half of the gap. The runtime raises the database trigger events (OnBeforeInsertEvent, OnAfterInsertEvent, and their modify, delete, and rename counterparts) on every database operation and only passes the RunTrigger flag to the subscriber, so every subscriber that does not exit on RunTrigger = false still runs, in the calling company, against the calling company's setup, number series, and companion tables. The row lands in the target company, the side effects land in the caller, and nothing reports an error. The per-row cost of the call is a separate concern, see changecompany-in-loop-drops-caches. Upgrade code must not use ChangeCompany at all, see no-changecompany-in-upgrade.

Best Practice

Use ChangeCompany to read. Access rights in the target company are still enforced, so reads are safe. When the goal is business data in another company, run the code in that company: StartSession takes a company name and runs a codeunit there, so triggers, validation, and subscribers all execute with the target company as their context. StartSession is a background session, not a synchronous call: the Ok return value reports only whether the session started, not whether the codeunit's work inside it succeeded, the caller's transaction does not extend into it, and an error raised there does not come back to the caller — it has to be logged or telemetered from inside that session. Reach for StartSession only for work the caller does not need to confirm before it continues; a write whose success the caller must know synchronously needs a durable status or error channel (a field the caller polls, a job queue with retry) rather than a bare StartSession call. Learn notes that a background session costs as much as a user session to start, so batch the work rather than starting one session per row, or let the target company process a hand-off row on its own schedule. A direct cross-company write is acceptable only as such a hand-off into a table the writing extension owns, whose triggers do not read company data and whose trigger-event subscribers exit when RunTrigger is false, using Insert(false), Modify(false), or Delete(false), and never Validate.

See sample: changecompany-runs-triggers-in-the-calling-company.good.al.

Anti Pattern

An Insert, Modify, Delete, or Validate on a record variable after ChangeCompany(<name>), on a table whose triggers or trigger-event subscribers read setup, consume a number series, or write companion rows. With RunTrigger = true the trigger code fills the row from the caller's setup. With RunTrigger = false the trigger code is skipped, but the subscribers still fire in the caller, so a counter, log, or companion row maintained by a subscriber is written in the wrong company, and a caller that also updates the target by hand counts twice.

Detection signal: a record variable that has had ChangeCompany called on it with a company name and is later used with Insert, Modify, Delete, or Validate, where the table is not owned by the extension, or has triggers that read company data, or has trigger-event subscribers that do not exit on RunTrigger = false. Do not flag reads after ChangeCompany; writes with RunTrigger = false into an owned table whose triggers do not read company data and whose subscribers exit on RunTrigger = false; or ChangeCompany() without an argument, which points the variable back at the current company.

See sample: changecompany-runs-triggers-in-the-calling-company.bad.al.

See also