6.3Good practices & pitfalls
The essentials in 30 seconds
- Verify: joins and grain first, each total on its floor, cross-checked against a known value.
- Lighten: filter server-side, generic parameters, systematic IsNull, subreports outside Details.
- Keep it clean: sober formatting, test on a real volume — a wrong but pretty report is still a wrong report.
Farès thread — the rule stuck on the wall
After one quarter, Farès stuck his rule on the wall in Algiers: correct and clear first, fast next. What counted most was not a tool, but three habits — checking the joins first, filtering server-side, cross-checking before distributing — and his biggest narrowly avoided trap: a pretty statement with unverified totals, blocked before it was sent to management.
Pick a single habit to anchor into your routine, then move to the next one.
The do / don't of a professional report
The difference between a reliable statement and a wrong or slow report comes down to a few habits. Here are the ones that come up most.
✓ Do
- Check the joins and the data grain first (no duplicates).
- Place each total at the right level (subtotal in group footer, grand total in report footer).
- Filter server-side and fetch only useful tables/fields.
- Use parameters for a generic, reusable report.
- Handle null values (IsNull) and check formula syntax.
- Sober, consistent formatting; numbers/dates formatted, columns aligned.
- Cross-check totals against a known value before distributing.
- Test on real, voluminous data, not just a sample.
✗ Avoid
- Summing amounts duplicated by a one-to-many join.
- A summary at the wrong level (a total that means nothing).
- Filtering on a complex formula: processing shifts client-side (slow).
- A linked subreport in the Details of a large report.
- Too many colours/charts: the information drowns.
- Distributing a pretty but WRONG report (unverified totals).
- Testing only on little data (collapse in production).
- Hard-coding database credentials during integration.
Ready-to-say script — checking your statement before distributing (30 s)
“Clean joins? Totals at the right level and cross-checked? Server-side filter? Nulls handled (IsNull)? Sober formatting? Tested on a real volume? If any no, I fix it before distributing.”
Copy-paste template — pro grid before distribution
Pro grid before distribution:
[ ] clean joins, grain checked, no duplicates
[ ] totals at the right level + cross-checked (known value)
[ ] server-side filter (SQL checked), useful fields
[ ] IsNull handled + formula syntax OK
[ ] sober formatting, numbers/dates formatted
[ ] tested on real volume, PDF pagination OK
Small business / tight budget
One habit per quarter is enough: joins + cross-check first, the rest next.
Algeria SME
Fit routines to closes: a cross-check and volume-test slot held every month.
Remote / hybrid
The no. 1 discipline at a distance: cross-check and verified SQL written down, even for small statements.
Cross-cultural
Check local formats rather than assuming: an unusual number or date must alert everywhere.
48h challenge — apply tomorrow
Screen your next statement: zero distribution without cross-check, zero client-side filter, zero sample-only test. Fix the first gap found.
- I know the 8 reflexes to apply and the 8 pitfalls to avoid.
- I have checked my 3 critical points (joins, cross-checked totals, server filter).
- I have done the 48h challenge or scheduled its date.
Before distributing his statement, which reflex protects Farès best?
A good statement designer is not the one who produces fastest, but the one whose totals are correct and verified.