Posted by admin on Monday, June 23, 2008 at 2:24 PM

We tell our kids that "hate" is a strong word and to be careful about the words they choose because they reflect the content of their hearts.  That said - I hate making subreports in Visual Studio.  I do it just infrequently enough to forget all the little things you have to do to get them working.  Consequently I end up looking at the world's most useless error message: "Error: Subreport could not be shown".  Never again my friend; this time I'm going to write it down.

In my experience a lot has to go right and pretty much nothing wrong when setting up a subreport for it to work.  I adhere to the following voodoo rituals guidelines:

  • If you can avoid subreports altogether, then do.
  • Remember to configure the parameters for the subreport itself.  The configuration dialog is accessed by right-clicking on the design surface outside of the report boundaries (the gray area) and choosing "Report Parameters" from the context menu.
  • The first time you drag a column from a data source table onto the parent report the IDE makes a reference to that data source in its underlying XML.  Be sure to do this for at least one column of each table that will serve as sources for parameters in a given subreport before configuring the subreport.  Doing this will ensure that the source columns will be available in the subreport configuration dialog of the parent report. 
  • When you specify the report to show in the parent report's subreport control, remember to configure the parameters on the "Parameters" tab of the configuration dialog.  The dialog is accessed by right-clicking the control.  All of the subreport parameters (Parameter Name) must be specified along with their source (Parameter Value).  Watch for spelling and case errors.
  • If you have to modify a table adapter in a typed dataset used by a subreport and that modification adds a column to the table adapter, then it is better to delete the table adapter from the typed dataset and recreate it with the same name with the necessary changes.  I just recently tried modifying an existing table adapter in this way and broke a report that had been working.  Yea, I know.  It's crazy.
  • Sadly, It is often easier and faster to delete and recreate a subreport (and if necessary its parent report) than to troubleshoot one that isn't working.
Comments [0]     Categories: Reporting Services