Consistent crash when using Crystal Reports 2008 Runtime SP3

[Former Member]

Hi,

We are currently using the Crystal Reports 2008 runtime SP1 with our .NET application to generate Crystal Reports. Some of our clients complained about the export to RTF and XLS bug associated with the runtime 2008 SP1. In order to provide a fix to them, we installed and tested the runtime 2008 SP3 (as well as the Fix Pack 3.1) but it is unfortunately not a working solution. It successfully generates a Crystal Reports once only and then crashes for any other attempt (same report or different report).

In order to isolate the problem we wrote a little program in Visual Studio that reproduces a simplified code sequence of the calls we make to the Crystal runtime. It always crashes on the second attempt to generate a report. It seems to be a buffer overrun, that occurs in a thread other than the main thread.

We have proceeded to testing on Windows XP and on Windows 7. Same problem all the time. We are using .NET. As for the runtime 2008 SP3, we made our own solutions from the merge modules, and also installed the full redistribuable build, always the same issue.

Here is the main part of the C++ code :

ReportDocument^ RD = nullptr;

try
   {               
   RD = gcnew ReportDocument();
   RD->FileName = gcnew System::String("C:\\AbsStat.rpt");
   Database^ ReportDatabase = RD->Database;
   Tables^ ReportTables = ReportDatabase->Tables;
   System::String^  SourceFileName   = gcnew System::String("C:\\AbsStatb.xml");
	for (int i = 0; i < ReportTables->Count; i++)
	   {
	   Table^ ReportTable = ReportTables<i>;
                          // Set the source file name to the table
      ReportTable->Location = SourceFileName;

                          // Test the connectivity of this data source
      if (!ReportTable->TestConnectivity())
         return (false);
      }

   System::String^  FileName   = gcnew System::String("Alex.pdf");	
   RD->ExportToDisk(CrystalDecisions::Shared::ExportFormatType::PortableDocFormat, FileName);
   }
catch (System::Exception^ e)
   {
   return (false);
   }
finally
   {
	if (RD != nullptr)
	{
		RD->Close();

I can provide the complete Visual Studio solution to reproduce the problem if needed. Any solution ? Thanks.

[Former Member · Accepted solution]

Are you still having this problem. I was experiencing a similar problem that has mysteriously stopped occurring. It began with a move from Office 2007 to Office 2016.  Today, everything is working as normal...

[former_member11696]

Hello,

Can you add the OpenReportMethod.OpenReportByTempCopy to your open method. I'm wondering if the report is not defaulting to this default open method. ANd locking the file.

What happens if you export to some other format? To see what formats are having problems, it could be the export dll causing the problem. Although you indicate they are using RTF but your code is using PDF?

What happens if you use a different data source other than XML?

What happens if you use a report with saved data and not do the log on method or test connection?

What happens if you don use the TestConnectivity API?

Not many people use C++ so you may want to purchase a case on line so sample app's can be passed back and forth as well as log files.

If this is a bug you'll get a refund.

http://store.businessobjects.com/store/bobjamer/DisplayProductByTypePage&parentCategoryID=&categoryI...

Thank you

Don

[former_member11696]

Oh and I'm curious why you are using C++ rather than C# as your programming language?

And what happens if you don't export, just close the report and then re-open it?

Thanks again

Don

[Former Member]

Hi Don,

Thanks for your quick answer and hints to try resolving this issue.

Oh and I'm curious why you are using C++ rather than C# as your programming language?

The application we are developing is a very big and complex optimization application that recently celebrated its 30th birthday. C++ was a suitable programming choice for such application.

And what happens if you don't export, just close the report and then re-open it?

It is a question of loading the dlls. We have a submission window that loads the dlls, we haven't got to the point yet where you chose to print or export and nor to which format. It crashes on load (second load).

What happens if you export to some other format? To see what formats are having problems, it could be the export dll causing the problem. Although you indicate they are using RTF but your code is using PDF?

Same as above. The format shouldn't matter. I mentionned RTF because the known export problem with RTF using SP1 is the reason why we want to upgrade to SP3. We mainly export to PDF but some of our clients export to RTF and XLS as well.

What happens if you use a different data source other than XML?

We cannot as it is the only data source type we are using to send data to Crystal Reports from our application (ADO.NET (XML)). We have not tried other data source types for that reason.

For the other questions we are currently proceeding to testing and I will post results as soon as possible.

Thanks for your help.

Anthony

[former_member11696]

Hello,

"What happens if you export to some other format? To see what formats are having problems, it could be the export dll causing the problem. Although you indicate they are using RTF but your code is using PDF?

Same as above. The format shouldn't matter. I mentioned RTF because the known export problem with RTF using SP1 is the reason why we want to upgrade to SP3. We mainly export to PDF but some of our clients export to RTF and XLS as well.

What happens if you use a different data source other than XML?

We cannot as it is the only data source type we are using to send data to Crystal Reports from our application (ADO.NET (XML)). We have not tried other data source types for that reason."

These were suggestion for testing purposes, try something other than RTF and PDF. Sometimes some formats work and others don't. Same for data sources, using a report with saved data removes the database as the source of the problem. For debugging purposes only, the various other formats can tell us if it some setting before exporting happens or if the issue is within the exporting or set database location functions.

Simplify as much as possible to help narrow down where the actual cause it.

Thank you

Don

[Former Member]

Hi Don,

We have isolated the cause of the crash and modified our code accordingly. It is now working correctly. In the code sample I provided the crash was caused by the following line :

ReportTable->Location = SourceFileName;

We then replaced this section :

   Database^ ReportDatabase = RD->Database;
   Tables^ ReportTables = ReportDatabase->Tables;
   System::String^  SourceFileName   = gcnew System::String("C:\\AbsStatb.xml");
   for (int i = 0; i < ReportTables->Count; i++)
      {
      Table^ ReportTable = ReportTables<i>;
                          // Set the source file name to the table
      ReportTable->Location = SourceFileName;

                          // Test the connectivity of this data source
      if (!ReportTable->TestConnectivity())
         return (false);
      }

by this :

System::String^  SourceFileName   = gcnew System::String("C:\\AbsStatb.xml");
   System::Data::DataSet^ DS = gcnew System::Data::DataSet();
   DS->ReadXml(SourceFileName);
   RD->SetDataSource(DS);

As for the TestConnectivity() method, it works correctly and was not in cause regarding the crash. The problem was caused by the Location property of the Table object. Is there a bug with that Location property or has it been modified in such a way that it caused a crash of our application ?

Thank you for your help.

Anthony

[Former Member]

Hi,

Did you manage to sort this one? I am facing the same problem

[former_member183750]

CR 2008? Are you on the latest SP? If not, get it from here:

Downloads for SAP Crystal Reports and others

And create a new Discussion referencing this one please.

- Ludek

Senior Support Engineer Product Support, Global Support Center Canada

Follow me on Twitter

Got Enhancement ideas? Use the SAP Idea Place