Give Every Batch Its Own Buffer

Give Every Batch Its Own Buffer

A warehouse app stages pick lines batch by batch, and every consumer — a print job, a posting routine, a review page — asks the collector for one batch's lines. Two support tickets landed this week: batch B printed with all of batch A's lines attached, and after a teammate "fixed" that with a clear-before-fill, a batch report that had already been collected suddenly came out empty. Both tickets share one root cause: the collector keeps one temporary record instance and hands every caller a handle to that same instance.

That is the whole lesson. A temporary record variable owns an in-memory data set, and a global one lives as long as its codeunit instance — so inserting into it on every call piles new rows on top of what earlier calls left behind. And Copy with ShareTable = true does not copy rows at all: it turns the target variable into a second handle on the same data set, so every buffer handed out this way is the same buffer, and clearing or refilling it later silently rewrites results your callers already hold. The fix is to make the rows land in a data set the caller owns: the var buffer the caller passed in, cleared first, filled row by row.

Requirements

The starter ships two objects. The table "Batch Line Buffer" (TableType = Temporary; fields "Batch Code" Code[20], "Line No." Integer, Description Text[100], Quantity Decimal; primary key "Batch Code", "Line No.") — include it in your submission unchanged, the tests read its fields by name. The codeunit "Batch Collector" — working-looking, but built on the shared-instance pattern above. Restructure it so every dataset it returns is an independent, correctly reset temp set; its two public procedures must keep exactly these signatures:

procedure AddLine(BatchCode: Code[20]; LineNo: Integer; Description: Text[100]; Quantity: Decimal)
procedure GetBatch(BatchCode: Code[20]; var TempBatchLine: Record "Batch Line Buffer" temporary)