Hi all,
I'm working on a two-tier application that uses Crystal to talk directly with a database to generate reports. The application is primarily in C++, with a C# wrapper around the Crystal 13 .NET API. There's no web component to the application: it's strictly a desktop application (notwithstanding the database, of course).
We're at the tail-end of migrating from Crystal 9 to Crystal 13 (.NET). The bulk of development work is nearly done, but I've run into a problem where installations don't work. In particular, a remote debugging session to the application on the target machine reveals that the call to ReportDocument.Load() hangs on a machine with our application installed, whereas the call to .Load() works fine on my dev machine. The same problem occurs with ISCDReportClientDocument.Open().
I'll include the code (minus error handling) just for the record, but it's painfully simple:
public bool GetReportSchemaVersion(string reportName, out int major, out int minor)
{ // reportName is the full path to the .rpt file // (Temporarily) open the file, check its version, and close it. ReportDocument rpt = new ReportDocument(); rpt.Load(reportName); // Never returns from this on target machine. Switching to ISCDReportClientDocument.Open() doesn't change the behaviour. ISCDReportClientDocument rptClientDoc = rpt.ReportClientDocument; major = rptClientDoc.MajorVersion; minor = rptClientDoc.MinorVersion; rpt.Close(); return true;
}
If I try what the OP was doing in http://scn.sap.com/thread/1918746, I get the same behaviour that he gets (namely, it times out after a couple of seconds). (I know there's a suggested solution to his problem, but it didn't work for me.) I've seen other posts elsewhere that suggest that this could be due to printer issues, but I've made sure the target machine has a default printer driver installed, and that the report was saved with the "No Printer" option checked; similarly, yet other posts suggest that it could be due to file permissions, but I've tried moving the .rpt to non-permissioned folders and by running the app as admin, and that doesn't take care of it either. I've also tried calling this on a .rpt that's essentially empty (it has a single static text field), and .Load() still hangs.
The target machine is Win7-32bit; our application is 32-bit. The only Crystal 13 thing installed on the target machine is the 32-bit MSI for CR13 SP5 from http://scn.sap.com/docs/DOC-7824. (We've tried including the MSM in our installer but haven't succeeded yet due to [presumably] unrelated path length problems.) Our installer also includes the CR9 runtime (since we're ultimately hoping to run CR13 side-by-side with CR9 for now -- but that's a topic for another day).
I haven't installed anything RAS-specific on the target machine (nor on my development machine, as far as I know). The literature that I've found online is a little hazy on this issue: some references suggest that in-proc RAS is included in the redistributable, whereas others (usually older) references seem to imply that it requires activation via a purchased license. In any case, I haven't found any RAS-specific installations online. Is it possible that this is the culprit?
Any help on this would be appreciated!
Kevin
{
// (Temporarily) open the file, check its version, and close it.
try
{
ReportDocument rpt = new ReportDocument();
rpt.Load(reportName);
ISCDReportClientDocument rptClientDoc = rpt.ReportClientDocument;
major = rptClientDoc.MajorVersion;
minor = rptClientDoc.MinorVersion;
rpt.Close();
return true;
}
catch (Exception cerr)
{
string preambleMessage = "An error occured trying to get the Report File version for file: " + reportName + ".";
ShowExceptionToUser(MethodBase.GetCurrentMethod().Name, preambleMessage, cerr.Message);
major = UNKNOWN_FILE_SCHEMA_VERSION;
minor = UNKNOWN_FILE_SCHEMA_VERSION;
return false;
}
}