bcquality/microsoft/knowledge/performance/use-temporary-tables-for-intermediate-data.md
Jesper Schulz-Wedde 0540c7bf6e Reframe seed-article banners as community contribution invitations
The 35 articles still in their seed form previously carried a banner
reading "Seed article. ... Domain stewards should expand, restructure,
and refine as needed." For a community preview, that phrasing reads as
"TODO left in production" to first-time visitors.

Replace all three banner variants (performance-seeded, security-seeded,
community-ported) with a single positive invitation:

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

Content and structure of the articles are unchanged; only the leading
quote block differs. Articles that had their banner fully stripped in
the earlier triage pass (the showcase-grade ten) are unaffected.
2026-04-23 17:31:36 +02:00

27 lines
1.2 KiB
Markdown

---
bc-version: [all]
domain: performance
keywords: [temporary-table, in-memory, intermediate, working-set]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Use temporary tables for intermediate data
> Contributions welcome — open a PR to refine or extend this article.
## Description
Temporary tables live in memory, not in SQL. They are the correct primary data structure for intermediate results, working sets, and lookup caches that do not need to outlive the current operation. Using a real persisted table for scratch data incurs database round-trips, transaction scope, and locking for data that has no business being persisted.
## Best Practice
Declare the record variable with `temporary` when the data is scratch. Populate it with Insert(false) to avoid firing triggers. Clear the table explicitly with DeleteAll when the variable's scope is long-lived (a SingleInstance codeunit or a reused session variable) and needs to be reset between uses.
See sample: `use-temporary-tables-for-intermediate-data.good.al`.
## Anti Pattern
Writing intermediate results to a real table, processing them, and deleting them afterwards performs the full cost of INSERT and DELETE operations on data that never needed to be transactional.