It’s been a long time since I am working with Crystal. Be it support incidents or community forums, one issue never gets old is the Crystal print engine reaching its print job limit. This issue has been discussed many times on all fronts of Crystal support.
This blog summarizes all the information and suggestions we offer to the customers.
So, what exactly is a Crystal Reports ‘Print Job’?
A Print Job is essentially any action the print engine has to perform while generating a report. This includes paging, drilling, zooming and so on.
Note that a print job includes main reports, subreports, and in-session report objects (e.g.; drill down, paging, searching, and more.).
Possible errors / issues:
- COMException (0x80041016): The maximum report processing jobs limit configured by your system administrator has been reached.” Followed by Error “ Load report failed.”
- Application hangs / crashes after processing multiple Crystal reports, starts working fine after windows service or IIS restart.
Crystal print engine is designed with 75 as a default print job limit. Once this limit exceeds, above issues start to appear.
Sometimes the error is self-explanatory but sometimes one has to identify the scenario that too many print jobs are getting generated.
Consider a simple scenario where a Crystal report has 75 records and 1 subreport in details section. In this case the subreport being in details section will run for 75 times, once for each record generating 75 print jobs plus one print job for main report. So running a single report with one subreport could itself generate 76 print jobs and causing the issue.
Now imagine the same report being accessed by two users at the same time????
What to do now?
Let’s face it, there is only one issue here, the crystal print engine is being used too extensively but it is not designed for this much amount of load.
Standalone Crystal engine is meant for light reporting needs.
There are few things could be done to avoid this issue for a time being or reduce the frequency of the issue but these steps are not the solution. They may or may not work at all.
1. Adhere to precautionary measures, this means design the reports to generate minimum print jobs.
“Recently I was working with a customer facing this issue while printing the report for multiple times. Opened his report and guess what, 4 subreports in details section. That report won’t last for even 20 records”.
Don’t send more jobs than the product is capable of processing. So, revisit the report design.
See few suggestions here.
2. Use Crystal Cleanup code.
Make sure you are closing and disposing the ReportDocument object immediately when it moves out of scope. The ‘Where’ completely depends on the flow of the application.
3. 3. Increase the print job limit. Set it to
“HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Report Application Server\InprocServer”
“-1” value DOES NOT work with standalone Crystal Reports. It is for OEM edition ONLY.
Set it to any definite number (possibly 250 – 300).
Remember, increasing this value results in more of a strain on your server. There is a possibility of the application start to throw random error messages making no sense at all.
One good approach is to cache the report object instead of sessions.
This will allow you to share the report between multiple users. Keep in mind that reports that implement the ICachedReport class will be shared among users when the database and parameter information is the same. See the CR .NET SDK developer guide for more information.
Other code change is add a try/catch around the open/load report method, if it fails then handle the job ( cache it ).
The truth is, we don’t have an easy answer for you. If you are facing this issue, that means you are using the standalone Crystal report engine too extensively and you need a more robust solution.
You need Crystal Reports Server or BusinessObjects Enterprise.
Contact sales here: 866-681-3435.