“Show groups with more than ten units” is different from “show rows containing more than ten units”. A grouped Access query can answer either question, but placing the condition at the wrong stage changes which observations contribute.

Prepare a disposable table named UsageLines with GroupCode and Units fields. Give group A two rows containing 6 and 7. Give group B one row containing 11. Decide that the task is to show groups whose combined units exceed ten.

Apply the condition to the grouped result

Microsoft documents that WHERE selects records before Access groups them, while HAVING filters the groups after GROUP BY. For this example, use a copied SELECT query in SQL View:

SELECT GroupCode, Sum(Units) AS TotalUnits
FROM UsageLines
GROUP BY GroupCode
HAVING Sum(Units) > 10;

The expected grouped totals are A with 13 and B with 11, so both satisfy the condition. Putting WHERE Units > 10 before grouping would discard A's two source rows. That alternative would leave only B, because neither individual A row exceeds ten.

State the input rule separately

A real report may also need a row-level restriction, such as including only confirmed observations. Put that selection rule before aggregation when it determines which rows should contribute. Then apply a group-level threshold to the resulting totals. Write both rules in plain language before editing the SQL.

Check the source rows of one included group and one excluded group. Calculate their totals independently using the same input restrictions. Comparing against an unrestricted source total would test a different question.

Keep a boundary case in the disposable sample. A group totalling exactly ten should be excluded by > 10; changing the requirement to ten or more would require a different comparison. Do not change the comparison simply to obtain a preferred record count.

Save the reviewed query and its intended selection stages. Recheck the example after adding joins or changing the source, because those changes can alter the contributing observations before either filter is considered. A correct HAVING condition cannot compensate for a source set that already counts the wrong records.

Sources: Microsoft: Access HAVING clause.