0192

Two Filters That Compile and Lie

setrange
setfilter
customer
debugging

Two Filters That Compile and Lie

A colleague left a small reporting codeunit behind before moving on. It compiles, it runs without a single error, and both numbers it produces are wrong: CountWithoutSalesperson reports every customer in the company, and CountInRange reports 0 whatever range it is asked for. Nobody noticed for weeks because nothing ever crashed — each bug is a filter that looks right and quietly does something else.

Your job is to make the two numbers true.

Requirements

The starter contains a codeunit named "Customer Queries" with two public procedures. Keep the codeunit name and both signatures exactly as they are:

procedure CountWithoutSalesperson(): Integer
procedure CountInRange(FromNo: Code[20]; ToNo: Code[20]): Integer

Rules:

  1. CountWithoutSalesperson returns how many Customer records have a blank "Salesperson Code". A customer carrying any salesperson code must not be counted — the answer is never "every customer in the table".
  2. CountInRange returns how many Customer records have a "No." from FromNo through ToNo, both ends included: a customer numbered exactly FromNo or exactly ToNo counts, the customers numbered just before FromNo or just after ToNo do not. When FromNo equals ToNo, the range is that single number.
  3. FromNo and ToNo are plain customer numbers (letters, digits and hyphens only), and FromNo never sorts after ToNo.
  4. Both procedures answer 0 when nothing matches, and neither may raise an error.

Each procedure is one filter away from correct: the fix belongs on the filtering line. Only the counts are graded — how you arrive at them is not.

Keep the object ID in the house range 50100–50199 and reference other objects by name, never by ID.

What the tests check

The grading tests run in a real company that already contains customers, so CountWithoutSalesperson is graded as a difference: a test calls it, adds a mix of customers with and without a salesperson code, calls it again, and asserts that the count grew by exactly the number of customers added without a code — by a generated number of them in one test, and by zero in another where every customer added carries a code. CountInRange is graded with exact counts on customers created under a generated number prefix: five ascending numbers of which the middle three are asked for (both boundaries in, both neighbours out), a range whose FromNo equals ToNo, a generated number of customers inside a wider range, and a range that holds no customer at all, which must return 0. Fixing only one of the two procedures leaves the other's tests failing.

Learn More

Hint 1
Nothing crashes, so trace each call by hand instead: SetFilter is handed an empty string, SetRange is handed a string with two dots in it. For each, ask what the platform receives and what it does with it. The Remarks on the SetFilter reference page answer the first question outright.
Hint 2
SetFilter parses its second argument as a filter expression, and an empty expression means 'no filter' — the call quietly removes any filter on the field instead of matching blank. The other filtering method on Record takes plain values, never expressions, and a blank value is a perfectly good value to match.
Hint 3
SetRange never parses anything: whatever it is handed is matched literally, so FromNo + '..' + ToNo looks for a customer whose number contains two dots (the community LinterCop analyzer flags exactly this as LC0008). The same method has an optional third parameter — a from-value and a to-value — and that overload is the inclusive range you meant.
ALBusiness Central 28.5
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.