Skip to content

Why does it takes a long time to process or execute a Crystal Report at runtime?

It will take a long time to process when previewing an Info Service or a Quick Report of type Crystal. It’s also seen that it takes a long time for the IFS Quick Report Parameter Dialog to show the Quick Report Parameters. The issue drills down in to two ways where this performance issue can occur and is related to the 3rd party Crystal.Net API used by the IFS Crystal Web Service framework. When processing a Quick Report or Info Service report request the IFS Crystal Web Service will first try to read and load the layout in to a Crystal Document object in memory using the Crystal.Net APIs. The Crystal.Net API reads all sections of the reports and objects within the section and creates the object tree. This is the main entry point where this performance issue occurs.

The first performance issue comes when the Crystal.Net API will try to verify the design-time printer that is saved in the report (if any) when loading the report. If this printer is not found in the runtime environment (the machine where the Crystal Web Service is installed) or if the runtime printer driver is different to the design-time printer driver it will take time to load as Crystal tries to lookup the design-time printer. To fix this you can set the “No Printer” option from the “Print Setup” menu in the “File” menu. This will prevent Crystal from looking up the design-time printer and trying to read information from it at runtime.

PageSetup      NoPrinter

The second performance issue comes when the Crystal.Net API will try to verify and lookup the design-time database at runtime when loading the report. It will try to look-up the design-time database for each database connection in the main report and for each sub-report (if any). Also, it will try to lookup the design-time database for each and every SQL Expression in main report and sub-reports (if any). The Crystal.Net API will look-up the design-time database when loading the report and it will pool until the default database driver timeout is met. So high number of sub-reports and SQL Expressions a report have will lead to a high loading time. This seems to be a known issue from Crystal side but has not been fixed in Crystal Report XI R2. There are two manual fixes to resolve the issue.

Fix 1:

Add the design-time database service name which is mapped to a runtime database machine IP in to the host file in the machine where the IFS Crystal Web Service is installed. See the following details for more information,


1. Get the design-time database service name by going to “Database\Set Datasource Location” option, Here you will see the database service name used in the main report and the sub-reports.

SetDatasourceLocation      DatasourceLocation

2.Add the following to the host file in the machine where the IFS Crystal Web Service is installed. The host file is located in <Windows system32 directory\drivers\etc (e.g. C:\WINDOWS\system32\drivers\etc). Add an entry as following to the host file. You can map the same IP to different database service name. This will only mean that it will resolve the database service name as the same IP and will not have any other affect.

<IP of a runtime database> < database service name>  
10.17.25.122 IFSTEST75  
10.17.25.122 IFSPROD75

Fix 2:

Edit the layout and update the design-time database service name with a runtime database service name.

1.Go to “Database\Set Datasource Location” option

SetDatasourceLocation      DatasourceLocation

2.In the “Replace with” section use “Create New Connection” and create a “Oracle Server” connection for the runtime database.

ReplaceWith      OracleServer

3.Then select the new connection pointing to the runtime database then select the design-time database. This will enable the “Update” button. Pressing the this will update the design-time database with the runtime database. Follow the same steps for other design-time database for sub-reports.

Update

4.Save the report layout.