6.3 · Good practices & pitfalls

Level 6 · In practice

6.3Good practices & pitfalls

Goal: adopt the right statement-design reflexes and avoid the most frequent mistakes.
Estimated time: 10 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

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.
Common misinterpretation: “ticking every box every day”. No. These are habits to install one by one: pick one (e.g. cross-check everywhere), anchor it into your routine, then move to the next.
Text version of the diagram (SEO / screen readers / translation): Balance to hold: 1) Correctness side — clean joins, totals on their floor, IsNull, cross-check against a known value. 2) Speed side — server filter, useful fields, generic parameters, subreports outside Details. 3) Readability side — sober formatting, formatted numbers and dates, test on a real volume, never hard-coded credentials. Lesson: a good report is first CORRECT and CLEAR, then fast — correctness beats appearance.

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.

Caution: Generic reminder: golden rule — a good report is first CORRECT and CLEAR, then fast; never distribute an unchecked statement, never hard-code database credentials, and always test on a real volume.

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.

Section exit checklist
  • 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.
Self-assessment 1-5: consistency of good reflexes?pitfalls avoided?
Check your understanding

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.