Application crashing when generating many PDFs using Crystal Report and Thai language

[former_member1307965]

We are generating 145,112 PDFs using Crystal Reports in a multi-threaded loop.

After generating about 826 PDFs, our application will crash.

We have isolated the issue to a combination of Thai characters being printed into the report and using the PSL Kittithada Pro font.

Is there some sort of Thai multi-language support required when using Crystal Reports?

[former_member11696 · Accepted solution]

Altering that registry key will not affect the number of reports it can process sequentially, and best to leave it at the default 75.

You are using a Free version of the CR runtime, it's not capable of processing thousands of reports repeatedly, also called report bursting. To move up to the next version get Crystal Server, you can run up to 4 RAS Servers to process reports.

You can get it from here:

https://www.sap.com/products/crystal-server.html

Don

[former_member11696]

All I can suggest now is upgrade to SP 22 and see if the updated usp10.dll helps the issue

[former_member1307965]

Hi Don

I have upgraded to the latest version of Crystal Reports: 13.0.22.2668.

I am still getting a crash after running the service for about 2 hours and 46 minutes. In that time frame, it has genereated about 50,000+ PDF documents.

reporting-service-crash.png

Is there anything else I can do to fix this?

Thanks

[former_member11696]

I changed the Tag to CR for VS and then CR Designer.

What version of CR for VS are you using? Look in Programs and Feature, version should be something like this: 13.0.22.xxxx

You can get the latest from here:

https://wiki.scn.sap.com/wiki/display/BOBJ/Crystal+Reports%2C+Developer+for+Visual+Studio+Downloads

What may help is moving to SP 22, it uses an updated version of usp10.dll which if there are issues in the previous version it may be fixed.

When updating you must read the SP 21 info to update your project references etc.

Second problem/question is CR only supports TTF type font, if your font is not that then test with a ttf version of that font.

Open the report in CR Designer and click on View, Preferred Viewing Locale, and then More.... Scroll down and you should see Thai.

Set that, then right click on one of the fields and select the True Type Font.

Now preview the report multiple times and see it it works consistently.

I believe it's the font causing the memory issue, try a different font and see if it still has a memory issue in your app.

Don

[former_member1307965]

I'm using CR for VS version 13.0.9.1312.

I've also attached screenshots of the font. It does look like it is a True Type Font, doesn't it?

sap-crystal-reports-version.png

[former_member1307965]

1. The application is written in C#.NET.
2. Yes, the code does explicitly call .Dispose() on the ReportDocument instance. The instance is not in a "using" clause.
3. We're using a pool of ReportDocument instances that we re-use while creating the PDFs, is this alright in your view?
4. We have not much of a choice when it comes to sub-reports. We have to use them. Does the advise about reversing the order of setting connection info from this forum still valid?
5. I tried increasing the value of the PrintJobLimit in the registry to a higher value (ex. 999) but that doesn't fix my problem. Is there some sort of registry setting that I can tweak? The registry setting is:
   [HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET
   Framework 4.0\Report Application Server\Server]

[DellSC]

First off, I would look at a couple of things that are not related to the language and font....

What language is the application written in - Java, VB.NET, or C#.NET?

If it's either of the .NET languages, is the code ever explicitly calling .dispose() on the ReportDocument instance or is the instance in a "using" clause? If not, that could be at least part of your problem. The .NET SDK is built on a foundation of COM objects which .NET does not memory manage very well so things need to be explicitly disposed or the application's memory use will just keep increasing until all of the memory on the computer is used up.

A couple of other things that negatively affect memory usage are:

1. The use of "TotalPages" or "PageNofM". If these aren't used, Crystal will export each page as it is rendered. If they are used, Crystal has to render ALL of the pages before any of the report can be exported.

2. The use of subreports, especially if they're in a details section.

-Dell

[former_member1307965]

1. The application is written in C#.NET.
2. Yes, the code does explicitly call .Dispose() on the ReportDocument instance. The instance is not in a "using" clause.
3. We're using a pool of ReportDocument instances that we re-use while creating the PDFs, is this alright in your view?
4. We have not much of a choice when it comes to sub-reports. We have to use them. Does the advise about reversing the order of setting connection info from this forum still valid?
5. I tried increasing the value of the PrintJobLimit in the registry to a higher value (ex. 999) but that doesn't fix my problem. Is there some sort of registry setting that I can tweak? The registry setting is:
   [HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET
   Framework 4.0\Report Application Server\Server]

[DellSC]

Periodically, you'll want to call

Marshal.ReleaseComObject(reportdocument);

to get the program to release the memory that it's using for the ReportDocument.

Also, you can't really change the Print Job limit for the .NET SDK - it's limited to 100 concurrent print jobs by the runtime license. So, if you're multi-threaded and running multiple reports at the same time, you might run into issues. A "print job" is defined as a main report plus each instance of a subreport within that report. For example, if you have a subreport that only runs in the report header, you have 2 print jobs. However, if you have a subreport that runs in a details section and you have 100 records displayed, you have 101 print jobs, which will fail.

-Dell