0
votes

I have been given a legacy ASP.Net application written in vs2005 with CR 8. I am currently running vs2017 and CR 13.0.22.

The application interacts with a lot of different data and shows multiple reports and I was asked to modify 1 of them that is a parent report with 5 subreports. When I initially started work I ran the Verify Database on the parent report and was prompted to connect using schema/XML files that did not make it into the saved code base and are now LOST.

I re-created the 6 datasets/connections that connect to stored procedures for the data and refactored/redesigned all 6 reports to reconnect to the new datasets.

Now when I run the application I get the above mentioned error: Invalid Subreport Name

Here is the method that is generating the error:

public void GenerateReport(List<Report> Reports, CrystalReportViewer Viewer)
{
int rptcount;
Report mainreport;

// make sure there is only one main report in the list
rptcount = 0;
mainreport = null;
foreach (Report report in Reports)
{
if (report.IsSubReport == false)
{
rptcount = rptcount + 1;
mainreport = report;
}
}
if (rptcount != 1)
throw new Exception("ReportWriter.GenerateReport: There was more than one main report found in the list of reports. " +
"Only one can be the main report. The other reports have to be subreports.");

// generate the report
checkReportFile(mainreport.ReportName);
document = new ReportDocument();
document.Load(mainreport.ReportName);
document.SetDataSource(mainreport.DataSet);

/* Previously the next line was a call to setReportParameters and the code errored with the Invalid Subreport Name call. I moved that line of code to after the For Each and now the error occurs within the foreach loop on the first iteration. */

// attach sub reports to the main report
foreach (Report report in Reports)
{
if (report.IsSubReport == true)

/* This line throws the error */
document.OpenSubreport(report.ReportName).SetDataSource(report.DataSet);
}
/* This is the previously failing line that I moved to here */
setReportParameters(document, mainreport.ReportParameters);
Viewer.ReportSource = document;
}

I ran the code in the Debugger and stopped execution prior to the error. I then executed the "document.OpenSubreport(report.ReportName)" piece of the failing line in the immediate window and this is exactly where the error is thrown. The ReportDocument type/object is part of the Crystal Decisions library and it is not possible to drill any further down in that code so I do not have the data to determine what exactly is failing. I've looked at all the converted subreports over and over again and they all look perfect in the designer. How do I determine what is really failing here? Is there a way to parse the .rpt file to see if there is some sort of legacy junk in it that needs to be deleted? If I can't find an answer I will have to start over from scratch...

2

2 Answers

0
votes

Rather than using OpenSubReport, I suggest that you use the Subreports collection on the main report, testing for null. Then you can tell the caller that they have requested an incorrect subreport name if it doesn't exist.

Something like

foreach (Report report in Reports)
{
    if (!report.IsSubReport)
    {
        continue;
    }
    var subReport = document.SubReports[report.ReportName];
    if (subReport == null) {
        throw new Exception($"Subreport {report.ReportName} not found");
    }
    subReport.SetDataSource(report.DataSet);
}

And using the SubReports collection will also let you examine exactly which subreports were loaded. It's entirely possible that there is a subtle typo or even a case difference that might make a difference.

0
votes

I used competent_tech's advice but it didn't solve my issue. What I ended up doing was installing the full Crystal Reports (2008 unfortunately) app and opening the report with that IDE. The IDE gave me much more informative errors. The problem was that there were missed object replacement errors within the Formula Fields and the Grouping for the parent report and a couple of the subreports. I also moved the setReportParameters back to its original called position. It was great to have better more descriptive information and I recommend going back and forth between the Visual Studio CR design and the stand alone CR design to isolate errors.