ebceff2332
These articles capture BC-specific mechanics agents still invert: partial-record JIT on writes, Reset clearing SetLoadFields, HttpClient inside write transactions, and batched number series, plus negative guidance that stops over-eager Query and IsEmpty "fixes". Co-authored-by: Cursor <cursoragent@cursor.com>
1.5 KiB
| bc-version | domain | keywords | technologies | countries | application-area | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
performance |
|
|
|
|
Batch number-series calls instead of GetNextNo per insert
Contributions welcome — open a PR to refine or extend this article.
Description
Codeunit "No. Series".GetNextNo updates and locks the number-series line on every call. A tight Insert loop that asks for a number per row serializes every concurrent writer on that series — the classic SaaS posting bottleneck. Training data still copies the per-row C/AL NoSeriesManagement shape. Codeunit "No. Series - Batch" issues numbers in memory and writes the series line once via SaveState. NumberSequence is the alternative when gaps are acceptable.
Best Practice
Inside a multi-row insert, call "No. Series - Batch".GetNextNo per row and SaveState once after the loop when the series must remain gapless. Use NumberSequence.Next when holes are allowed. Do not replace a single OnInsert GetNextNo for one master record; that path is not the hotspot.
See sample: batch-number-series-instead-of-getnextno-per-row.good.al.
Anti Pattern
NoSeries.GetNextNo(...) inside repeat ... Insert ... until Next() = 0. Each iteration takes the series lock. The signal is "No. Series" (not "No. Series - Batch") in a loop that inserts more than one row.
See sample: batch-number-series-instead-of-getnextno-per-row.bad.al.