Spent a decade inheriting broken SSRS reports at manufacturing shops. One bug has burned me more times than any other and most SQL devs I work with have never heard of it.
The setup: your report is blank. You run the same stored proc in SSMS with the same parameters and it returns the expected rows. Nothing about the proc, the data, or the report has changed. You restart the report server. Still blank. You're two hours in and your CEO wants to know why the month-end numbers aren't rendering.
The cause is almost always SET options. SSMS defaults `ARITHABORT ON`. SSRS (via ADO.NET SqlClient) defaults it OFF. SQL Server's plan cache is partially keyed by SET options, so the same proc can end up with two completely different cached plans depending on who called it first. A bad plan built under SSRS's defaults can return zero rows even when the proc and data are fine.
How to confirm it in about 90 seconds:
-- Open a fresh SSMS window and run this as the FIRST line:
SET ARITHABORT OFF;
-- Then paste the exact EXEC your report uses:
EXEC dbo.YourProc
u/StartDate = '2026-01-01'
,@EndDate = '2026-03-31'
,@CustomerID = NULL
,@StatusCode = N'OPEN';
If you now get zero rows (matching the report), the plan mismatch is confirmed.
The immediate fix:
EXEC sp_recompile N'dbo.YourProc';
That drops the cached plan. Reload the report. Data should appear.
The permanent fix:
Add `SET ARITHABORT ON;` as the first executable statement inside the proc body. This makes the proc immune to caller-specific plan pollution from SSRS, scheduled subscriptions, linked servers, and ad-hoc SSMS sessions.
Gotcha, that cost me an afternoon once: if SSMS and SSRS both work fine individually but SSRS breaks when multiple users hit it simultaneously, you're looking at plan cache pollution, not a sniffing issue. The first user's plan gets reused for everyone, and if that first user submitted atypical parameters, the pool is poisoned for the rest of the day.
Happy to answer questions on this or any of the other patterns in the comments.