Share via

Facing issue in loading Report which contains Main and Sub report using Report builder in SSRS

Madani, Ramya Krishna 0 Reputation points
2026-05-08T07:20:52.6766667+00:00

we are working on SSRS Reporting using Report builder. we have a report which has a sub report in it which works well in Production Environment. The same report (RDL file) doesn't load anymore in QA Environment. after waiting 25-30 min, it shows error message that it has timed out. Stored procedure runs within short period of time in sql developer. Please suggest where should i look to fix this issue? Thanks in advance. 

we have compared all properties, configurations in both the environments are same, also rebuild indexes and updated stats at Database end but still report not working.

In the reporting services log file we can see error as there is no data for the field at the position 16

Can anyone help to resolve the issue. Attached error snapshot.

image (1).jpg

SQL Server Reporting Services
SQL Server Reporting Services

A SQL Server technology that supports the creation, management, and delivery of both traditional, paper-oriented reports and interactive, web-based reports.


Answer recommended by moderator

Erland Sommarskog 134.7K Reputation points MVP Volunteer Moderator
2026-05-08T12:12:17.6233333+00:00

So the issue is that the procedure runs for a long time when submitted from Report Builder, but it is fast when you execute it from SSMS. Have you verified that the procedure is actually executing? You should be able to see this from Activity Monitor. You can also use my beta_lockinfo to see current activity in SQL Server.

However, this behaviour, slow in the application, fast in SSMS is not unheard of. In fact, it is common enough that I have written an article that tries to explain this mystery and how you can troubleshoot it: Slow in the Application, Fast in SSMS?

Quick version: When running the procedure in SSMS, try this:

SET ARITHABORT OFF
go
EXEC YourProcedure

It may be slow now. My article explains what is going on.

Was this answer helpful?

0 comments No comments

1 additional answer

Sort by: Most helpful
  1. AI answer

    2026-05-08T07:21:19.61+00:00

    Based on the error in the SSRS log and the fact that the same RDL works in Production but times out in QA, focus on SSRS-side processing rather than the database engine:

    1. Check for rsProcessingError details
      • In the SSRS log, search for ReportProcessingException and the specific error text about "no data for the field at the position 16".
      • This typically indicates a data/field mismatch during report processing (for example, a field index or name expected by the report does not exist in the dataset returned in QA).
      • Use the full error text and stack trace in the log to identify which dataset and which report item (textbox, tablix, etc.) is failing.
      • For more guidance, see the rsProcessingError troubleshooting steps: view the full error text, use the Error List in Report Designer/Report Builder, and check the server logs for ReportProcessingException.
    2. Verify dataset schema vs. report definition in QA
      • Confirm that the stored procedure or query in QA returns exactly the same columns (names, order, and data types) as in Production.
      • The error mentioning a field at a specific position (e.g., 16) suggests the report expects a field that is missing or has changed position in the QA dataset.
      • Compare the RDL’s dataset field definitions with the actual result set in QA. If the QA database has different schema (extra/removed/renamed columns) or different result shape due to environment-specific data, align it with Production or update the report definition.
    3. Check subreport compatibility and versioning
      • When a main report uses subreports, the same version of the Reporting Services report processor must process all of them. If QA has a different SSRS version or if only some reports were upgraded, subreports can fail with processing errors.
      • Ensure the main report and all subreports in QA are deployed from the same RDL sources and are compatible with the SSRS version in QA.
      • If any report failed to upgrade, re-deploy or upgrade it so that the same report processor version handles both main and subreports.
    4. Validate expressions and field references
      • In both main and subreports, check expressions that reference dataset fields:
        • Make sure field names exist in the dataset and are spelled correctly.
        • Ensure filters and expressions do not reference fields that have errors or are missing.
        • Verify that filter expressions and filter values use matching data types; mismatched types can cause processing errors.
    5. Compare parameters and subreport parameter mapping
      • Ensure parameter definitions (names, data types, multi-value vs single, nullability) are identical between environments.
      • Verify that the main report passes parameters to the subreport correctly and that the subreport’s datasets handle those parameters without returning a different schema or error in QA.
    6. Reproduce and isolate
      • Run the subreport directly in QA with the same parameter values used by the main report to confirm it renders successfully and returns the expected fields.
      • If the subreport runs but the main report fails, focus on the parameter mapping and any expressions in the main report that reference subreport-related datasets.
    7. Use SSRS logs for deeper diagnosis
      • As recommended for rsProcessingError, use the SSRS log file on the QA server to get the exact dataset and field causing the error. The log path is typically similar to:
        • <drive>:\Program Files\Microsoft SQL Server\<Instance>\Reporting Services\LogFiles\ReportServerService_*.log.
      • Once the failing field/dataset is identified, adjust the QA database schema, stored procedure, or RDL dataset definition accordingly.

    After aligning the dataset schema, field references, and ensuring the same report processor version and subreport definitions in QA, the timeout should disappear because the report will no longer be stuck in repeated processing failures.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.