First, Do No Writes

First, Do No Writes

Every night a parsed file lands in a staging table, and the warehouse has two non-negotiable rules for importing it: either the whole import becomes stock receipt entries or none of it does, and the operators get a complete list of every bad row — not just the first one that died. Surviving a failing check is the easy half; the trap this task is named after is what the survival tool does NOT do: it undoes nothing that already happened, and this server refuses to let you write to the database inside it at all. Where your writes happen, relative to where you catch, is the whole design.

What you get

The starter ships five finished objects. Keep all five unchanged and include them in your submission — the grading tests reference them by name.

• Table "Import Staging Row" — primary key "Import Code" (Code[20]) + "Row No." (Integer); fields "Item Code" (Code[20]) and Quantity (Decimal). The parsed file; the tests seed it.
• Table "Stock Receipt Entry" — same primary key; fields "Item Code" and Quantity. The destination the import must land in — all of it or none of it.
• Table "Import Failure" — primary key "Import Code" + "Row No."; field Reason (Text[250]). The per-row failure report the operators read.
• Codeunit "Import Row Check" with procedure ValidateRow(StagingRow: Record "Import Staging Row") — the sealed check. It performs no database writes; returning without an error means the row is valid. It fails, checking in this order: a blank "Item Code" raises an error containing is missing an item code; a zero or negative Quantity raises one containing must be positive; a "Stock Receipt Entry" already occupying the row's key raises one containing was already imported. Every diagnostic carries a fresh check code, stamped into the message text at call time.