Fix the Slow Report Dataset

Fix the Slow Report Dataset

The month-end activity recap is a processing-only report: no layout, it just fills a staging table the finance team pulls into Excel. On the demo company it flies; on the customer's database it runs for eleven minutes, and the SQL trace shows why — a steady drizzle of one-row SELECTs, several per ledger entry, millions in total. Every number the report writes is correct; each one was just bought at retail price.

Your job: the same staging rows, a fraction of the statements. Tune the report — don't rewrite it into something else.

Requirements

The starter ships two objects. Submit both files and keep both object names — the tests bind to them:

• Table "Customer Activity Recap Line" — the staging table the tests read. Keep its fields exactly as shipped.
• Report "Customer Activity Recap" — the processing-only report you tune. Keep it a report with the Customer table as its top-level data item: the graders set a customer filter with SetTableView and run it with UseRequestPage(false).

What one run must produce:

1. A run first deletes every row of "Customer Activity Recap Line", then writes exactly one row per customer the Customer data item processes.
2. "Customer Name" is the customer's Name.
3. "Entry Count" is the number of the customer's "Detailed Cust. Ledg. Entry" rows.