locked
RDLC grouping and subreports with multiple datasets RRS feed

  • Question

  • I am working on an RDLC report that contains master-detail type information with multiple datasets containing categorized detail information for each master row.  I developed my report to first display all the detail records without any filtering to ensure that I could successfully execute the subreport and render results.  This worked fine.  After that, I added a List to the main report and had it reference the dataset containing master records with the list containing a label showing which master record and the subreport using the master id as a parameter.  The subreport processing event in my code filters the detail recordsets to the appropriate detail records and sets them as datasources for the subreport.  When I made these changes, the report stopped rendering, throwing the usual cryptic reporting error message referencing only the name of a dataset in the top level report that is unrelated to the master/detail relationship and works fine if I delete the subreport.

    I have not done a whole lot with RDLC, but I have successfully done master-detail reports with subreports using the same approach here.  The only difference that I can tell is this is the first time my subreport has contained multiple datasets.  Is this a usage pattern that doesn't work with RDLC or requires some special step to make work?

    Tuesday, August 16, 2011 2:57 PM

Answers

  • I found the answer and learned a couple of important lessons about RDLC along the way.  The first thing that I learned is that dataset names added to reports and subreports are case sensitive, so a stray capital or lowercase letter where not expected can break the report.  The second thing that I learned is don't focus too much on the dataset being listed in the error message as the problem because it could be a different dataset entirely.  At this point I'll take that particular error to mean "there's some kind of problem somewhere and you go figure it out".
    • Marked as answer by Kyle Burns Tuesday, August 16, 2011 5:50 PM
    Tuesday, August 16, 2011 5:50 PM

All replies

  • Further testing has shown that the subreport containing multiple datasets is not the issue because I have removed the additional datasets and have the same issue.  If I place the subreport in the main body of the report (passing a hard-coded parameter as master id) the report renders just fine, but as soon as I place the subreport in a List or Table the render operation fails.  Conceptually, I have the following datasets:

    • header
    • master
    • detail

     

    Header contains "top level" information to print on the report.  Master is a list of categories with zero or more related Detail records.  When I set up the table, I added a table to the report body and set its DataSetName to "master".  I then removed the header row and all but the left-most column from the table and added a new row within group to the detail section, leaving two detail rows of one column.  I set the top row to reflect the name of the Master record.  When I run the report at this stage, all the header information displays correctly along with the expected data in the table for master records.

    After performing this test, I dragged a subreport object to the second row, set its path property, and add the masterId parameter tied to masterId of the current row.  At this point when I attempt to run the code the rendering operation fails with the only message being the name of the header dataset.

    Tuesday, August 16, 2011 4:40 PM
  • I found the answer and learned a couple of important lessons about RDLC along the way.  The first thing that I learned is that dataset names added to reports and subreports are case sensitive, so a stray capital or lowercase letter where not expected can break the report.  The second thing that I learned is don't focus too much on the dataset being listed in the error message as the problem because it could be a different dataset entirely.  At this point I'll take that particular error to mean "there's some kind of problem somewhere and you go figure it out".
    • Marked as answer by Kyle Burns Tuesday, August 16, 2011 5:50 PM
    Tuesday, August 16, 2011 5:50 PM