Level 6 · In practice

6.2Recurring problems (playbook)

Goal: have a “symptom → causes → actions” playbook for common report problems.

Estimated time: 12 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

Diagnose: one symptom = likely causes = a sequence of actions — never fix at random.
Roots: joins, summary levels, server-side filtering, sorting before running totals, null handling — 90% of incidents.
Verify: cross-check against a known value and test on a real volume, not just a sample.

Farès thread — the table taped next to the screen

Farès keeps this table next to his screen in Algiers. Verdict after one quarter: three lines served him most — inflated totals, the very slow report, and the inconsistent running balance. For each one, he ended up applying the sequence (symptom, causes, actions) instead of fixing at random.

Observed symptom, verified causes, actions in order: the reflex holds in three steps.

One reflex per symptom

Most wrong or slow reports fail for classic reasons. Linking each symptom to its likely causes and to a sequence of actions saves precious time.

Symptom	Likely causes	Actions
Totals are inflated / wrong	join duplicates (one-to-many), wrong summary level	check the joins (N0); cross-check against a known value; place the summary at the right level (N2.2)
The report is very slow	client-side filtering, everything fetched, subreport in the Details	filter server-side (check the SQL), take only useful fields, subreport at group level (N2.3, N5.4, N4.1)
A running balance is inconsistent	unsorted rows, reset misconfigured	sort first (by date), set the reset (never / by group) (N3.3)
A formula fails or returns blank	unhandled null value, incompatible types	test IsNull first, convert (ToText/ToNumber), check the syntax (N3.1, N3.4)
The PDF overflows in width	too many columns, portrait orientation	switch to landscape, reduce columns, check the printable area (N5.1)
Groups/rows split across two pages	no “keep together”, unmanaged breaks	Section Expert: keep together, new page, remove blanks (N2.5)
A cross-tab is unreadable	high-cardinality field in columns	few values in columns, numerous dimension in rows, group more coarsely (N4.3)
The chart blurs the message	wrong type, too many categories/series	bars/line/pie by message, Top N, “Others” (N4.2)
The parameter does not adjust the report	parameter not built into the filter	build it into the selection (“… = {?Param}”), server-side (N2.4)

Common misinterpretation: “the table replaces diagnosis”. No. The table gives likely causes, not a verdict: observe the symptom, verify the cause (joins, total levels, server SQL, sorting, nulls), then apply the targeted action.

Text version of the diagram (SEO / screen readers / translation): Table method: 1) Name the observed symptom (inflated totals, slowness, inconsistent running total, blank formula, overflowing PDF, split groups, unreadable cross-tab, confusing chart, inactive parameter). 2) Keep the likely causes from the table without concluding alone (joins, summary levels, client-side filtering, sorting, nulls, pagination, cardinality, chart type). 3) Apply the actions in order (N0, N2.2, server SQL N2.3, reset N3.3, IsNull N3.1/N3.4, landscape N5.1, keep together N2.5, rows vs columns N4.3, Top N N4.2, {?Param} N2.4). 4) Fix at the root (the same failure coming back = a missing reflex). Lesson: a recurring defect calls for a setting, not random fixes.

Ready-to-say script — diagnosing without fixing at random (30 s)

“My symptom: [inflated totals / slowness / inconsistent running total / blank formula / overflowing PDF / inactive parameter]. I check the likely cause from the table (joins, total levels, server SQL, sorting, IsNull), I apply the targeted action and I cross-check against a known value.”

Copy-paste template — report incident sheet

Incident: [observed symptom].
Likely cause: [joins / summary level / client filter / sorting / nulls / pagination].
Action: [check joins N0 / move summary N2.2 / server filter N2.3 / running-total reset N3.3 / IsNull N3.1].
Cross-check: [total vs known value] on [real volume].

Small business / tight budget

No formal table: one symptom, the likely cause, the action and who cross-checks, noted down.

Algeria SME

Build local realities into the diagnosis: real database volume, PDF printing workstation, known contact person.

Remote / hybrid

Add written traces to actions: at a distance, a verified SQL and a recorded cross-check figure avoid duplicates.

Cross-cultural

Spell out findings in writing: what seems obvious (which total, which filter) is not obvious to everyone.

Caution: Generic reminder: the same failure coming back is not ten incidents — fix the reflex at the root (joins, total levels, server-side filtering, sorting, null handling) and always cross-check before distributing.

48h challenge — apply tomorrow

Spot 1 current symptom (inflated totals, slowness, inconsistent running total), apply the table row (named symptom + verified cause + targeted action) and cross-check.

Section exit checklist

I can link a symptom to its likely causes.
I check joins, total levels and server SQL before fixing.
I cross-check every total against a known value on a real volume.

Self-assessment 1-5: diagnosis before fixing?systematic cross-check before distribution?

← Previous : Real-life cases (V3)Next : Good practices & pitfalls (V3) →

Check your understanding

Farès totals are inflated. Which reflex does the table prescribe?

💡

Reflex: diagnose the symptom, identify the cause, apply the targeted action — do not fix at random.