Latest Entry, One Read

Performance

Easy

findlast

cust-ledger-entry

sql-budget

Latest Entry, One Read

Support has a "latest activity" box on the document inquiry page: for any document number, it shows the most recent customer ledger entry posted under it. The helper behind it works — and the DBA hates it: for a document with sixty entries it drags all sixty across the wire just to keep one of them. The newest entry is one row; fetching it should cost one row.

Requirements

Create a codeunit named "Latest Entry Finder" with one public procedure:

procedure FindLatest(DocumentNo: Code[20]; var CustLedgerEntry: Record "Cust. Ledger Entry"): Boolean

Rules:

Consider every Cust. Ledger Entry whose "Document No." equals DocumentNo exactly — entries of other documents must never leak in, however recent they are.
The latest entry is the one with the highest "Entry No." — entry numbers only grow, so the biggest number is the newest posting.
When at least one entry matches, return true and hand that latest entry back in CustLedgerEntry — the tests read "Entry No." and "Sales (LCY)" from it.
When no entry matches, return false. The procedure never raises an error, even when the table is full of entries for other documents.
The row budget: one call must read at most 10 rows (SessionInformation.SqlRowsRead), no matter how many entries the document has. Grading seeds a document with dozens of entries — walking them all to find the newest reads every one and fails.
The statement budget: the same call must execute at most 3 SQL statements (SessionInformation.SqlStatementsExecuted). Going back to the database once per entry can never fit.

What the tests check

The grading tests seed ledger entries under TRYAL-* document numbers; amounts and entry counts are generated fresh every run, so hardcoded answers fail. The newest entry of the multi-entry document deliberately carries the smallest amount, so "biggest amount" is not "latest". A decoy is planted: an entry posted later under a different document number, which must not win over the requested document's own latest entry. One document has no entries at all and must come back false while other documents' entries exist. The budget tests warm the caches with one throwaway call, then invalidate the server's data cache — a repeated call served from cache memory costs zero SQL, so cached reads can't smuggle the chatter past the budget — and snapshot the SessionInformation counters around a second call: rows read on an entry-heavy document, and statement count on the same shape of data. The tests run in a real company with existing data, so your result must be driven purely by the "Document No." filter.

Learn More

Hint 1

Count the rows, not just the statements: the loop reads every entry of the document only to keep one of them. The database can hand you the newest entry directly — ask a question whose answer is a single row.

Hint 2

Records come back sorted by the current key. Filtered to one document, the primary key "Entry No." already orders the entries oldest to newest — so the newest matching entry is simply the last one in that order, and there is a Find call that fetches exactly that end of the set.

Hint 3

SetRange the "Document No.", then replace the whole FindSet/repeat block with a single FindLast: it asks SQL for TOP 1 in descending key order — one statement, one row — and fills the record with the newest matching entry. No loop, no comparison.

ALBusiness Central 28.4

Press Compile to check your code compiles — Submit runs the tests.

The code editor is desktop-only

Open this problem on a computer to write and run code. Reading the description, tests and discussion works fine here.