The script you are executing is taking longer than expected..[Continue]

1 May 2008

Issue Description


From a Technical Perspective, This Dialog is opened by the "Windows Script Control" which is used to run "Vbscript" code from Forms Printer, Forms Printer uses Vbscript to manipulate the Crystal Reports COM API in order to request the report be printed by the Crystal Engine.


If the Crystal Engine process of printing takes longer than the default timeout of the Windows Script Control (10 Seconds, I believe is the normal Script Control Timeout), then this dialog will appear.


The Appearance of the Dialog should not slow down the Report Running, it is rather , the slowness of the Report running that causes the dialog to appear.


You can change the Default Timeout for when this dialog appears, so that you will never see the dialog, but note that making this change will not by itself speed up your report.


See notes below - (esp make sure that your report is 'Generic' - i.e. Designed with a DSN name that will _not_ exist at runtime see the *[] note below )


Note 1:  "Script Timeout message" information


If you are getting the "Script Timeout" (a script is taking longer than normal... abort or continue) dialog when printing a report,


The script timeout usually occurs for the following reasons:

- The volume of data being returned/executed is exceptionally large, or the SQL Query is not efficcient (Microsoft SQL Profiler should be used to Analyze and possibly optimize  the SQL Query being executed by the report)

- The report is not truly 'generic' per Forms Printer documentation p. 36 (procedure varies depending on your version of Crystal).  (not usually the issue if Crystal 8.5 engine is actually being used, you may be using a newer crystal runtime if Dlls are present in c:\Program Files\Common files\Crystal Decisions or c:\Program Files\Common files\Business objects)


(note that you should always be sure the Report has been Verified against the current Great Plains database when upgrading, as Crystal may be slowed by trying to adapt to database/table changes due to the upgrade. )


 - The Crystal report being run may be designed in such a way that the execution of it is too slow. Take a look at the report to see if there are any possibilities for improvement to its design. Examples of performance improving changes would be: Left Outer joins that could be changed to inner, removal of unneeded tables, etc

To avoid getting the "Script is taking longer than expected to execute" dialog, you can increase the script timeout (default is 10 sec) on their installation. This can be accomplished for a particular workstation by adding the following dex.ini setting (works only if you have Forms Printer 8.0 build 22 or greater) .  (this _only_ inhibits the dialog, it would not speed up the report. )

Example add or modify the dex.ini setting to :

ASIFPVBSTIMEOUT=-1 (that's a negative 1)

Will disable the VBScript Script Control Timeout completely.


Will set it to 10,000 milliseconds (10 Seconds), the default.  (you may wish to set it to 30000 for instance)

*[(The following note , usually only an issue for Crystal 9.0 or greater Runtime Engine.)]

IF  you find that the Crystal reports printed from forms printer in a batch are taking significantly longer as each successive report is printed (during forms printer "Delivery" of a batch or group of invoices/statements) - then there is one thing we have found that sometimes impacts the report startup time such that the first report printed is 'fast' and each successive one gets quite a bit slower - if this is the characteristic of the  behavior you are seeing, then it is important to check to be sure that your Crystal Reports have been designed as 'Generic' in that they are designed using an ODBC DSN name that will _Not_ exist at report runtime on the client machines. 



We have found in a few cases that successive prints of  the report will run faster (and not degrade) if you open it in the Crystal Reports Application and set the ODBC DSN for the report (and any sub reports) by using "Set Datasource Location" , to a DSN that will NOT exist on the workstation when the report is eventually printed (see the forms printer documentation FPDOCNN.pdf in the Great Plains Application folder) Appendix 1 describes setting the DSN for the report to a temporary dsn, and then deleting that Odbc dsn to make sure that it will not exist on any machine which the report is printed from. (this method is applicable to Crystal 9 and above) - having the DSN not exist at report runtime, allows the Forms Printer code to Fall back to the Great Plains Connection parameters, which for unknown reasons, has been found to improve performance (non degrading performance on multiple prints) in some cases.

We have found in several cases involving Crystal 9 or greater components that This process improves performance of the report,  Please let us know if it works for you. (But note it is not a "cure all" for slowly executing reports that are bound by their report generated SQL queries , so after taking this step, if the report is still slow, you should use the Microsoft SQL Profile to see what SQL Query it is executing, and attempt to optimize that on the SQL Server or by changing the report design. )


Site Map