We have a large number of rather old and very complex SSRS reports (multiple sub-reports, huge number of parameters, original author long gone, etc).  

Our preferred export method is PDFs.  Some reports are quite large, even up to 100+ pages.  So far as I know there are no logic errors and these reports have not been modified in years.  Also the Windows Server 2008 report server is overdue for replacement.

From time to time a sub-report will fail leaving messages like 'Subreport could not be show.'   In this latest case the sub-reports work normally if run by themselves.

I've been assuming that the sheer size and complexity of the overall reports is what's causing the problems.  One of the sub-reports that failed this latest time around is a table with 30+ pages.

Assuming there are no gross logic errors, could sheer quantity of returned data cause this sort of problem?  Is there something else we might look for?

Hi B. Chernick,

According to my knowledge, the error "Error: Subreport could not be shown " occurs when one of the following conditions is true:

1. Not all the parameters of the subreport have been assigned a value.
   
2. The main report has a Parameter, which allowed blank and null values. In the subreport this paramterer was linked to another parameter which did not allow nulls or blanks.

In this case, if we link the parameters of the subreport to a field or a parameter in the main report, and if we change the filed or the parameter using report definition, but didn't update the reference(main report -- subreport), we may encounter the issue.

In addition, it is a known issue that we get the Error message when we view a report that contains more than one subreport in SQL Server 2008, the fix for this issue was first released in Cumulative Update 4 for SQL Server 2008 and Cumulative Update 1 for SQL Server 2008 Service Pack 1. Please download and install the proper CU based on your SQL Server environment. Here is the KB article link:
http://support.microsoft.com/kb/967749

If you have any more questions, please feel free to ask.

Thanks,
Wendy Fu

If you have any feedback on our support, please click here

I'm afraid I'm not sure that applies to this situation.  Admittedly this report is extremely complex in places but as I said earlier it's been in use for years and hasn't been modified recently.

For example, there's one sub-report that has been repeated crashing but it has no db queries and only 2 boolean parameters.  In keeping with our practices all booleans in our reports are not allowed to be null and have default values.  In the case of this particular sub-report, I've checked all the way from main down to the sub-report and it appears that the parameters are set up uniformly all the way through.  There seems to be no reason at all for this frankly simple-minded page to crash.  It's little more than one big literal.  (The parameters merely control the hidden values of various text boxes.)

A postscript:  A few minutes after I posted this we had another similar incident reported by a user in a different report.  When I tested the report, it ran normally.  Frankly until I see evidence to the contrary, I have to assume that these incidents are 'hiccups' brought about by server or network performance issues (and we do have our share of those.)

• Edited by B. Chernick Monday, January 26, 2015 4:20 PM Additional info

Hi B. Chernick,

Large amounts of data passed as network traffic can introduce wait times for the user. Depending on your expected user base and the expected volume of report views, you can select the appropriate approach for deploying report server components.

To reduce the wait times for the user, we can keep the report server catalog on the same computer as the report server. There are other ways to improve Report Performance, please refer to the following document: https://technet.microsoft.com/en-us/library/bb522806(v=sql.105).aspx#Data

If you have any more questions, please feel free to ask.

Thanks,
Wendy Fu

Very interesting reference.  (We're probably made a few of those mistakes.)

Is this still largely accurate for SQL 2012?  (Or are they going to release an updated version?)

Hi B. Chernick,

There is no such document of SQL Server 2012, the document is suitable for SQL Server 2012.

If you have any more questions, please feel free to ask.

Thanks,
Wendy Fu