![[spacer]](1p.gif){kind=small}
Under normal circumstances, the seven foreground call stacks are adequate for all processing needs. However, you must exercise caution when you use the run script statement in your application. The run script statement suspends the current script and causes a field change script (an attached script) to be run. Like all other attached scripts, a field change script requires its own call stack.
How you use the run script statement determines how many call stacks are required. If a single script executes several run script statements, only one additional call stack is needed. This is shown in the following example.
|
Script name: |
A |
run script 'B'; run script 'C';
Script A uses run script to start scripts B and C. Only one additional call stack is used because once script A starts script B, script A is suspended. Script B finishes and its call stack is available to process script C.
If run script statements are “nested,” the likelihood of using all of the call stacks increases. For example, if script A uses run script to start script B, which uses run script to start script C, three call stacks are used.
|
Script name: |
A |
run script 'B';
|
Script name: |
B |
run script 'C';
If enough nested run script statements are executed, all available call stacks will be used. If you then execute another nested run script statement, try to run an attached script, print a report that contains a calculated field which uses a function, or cause one of the automatically executed procedures to execute (such as by opening a table which causes the Pathname procedure to run), you will receive the message “All call stacks are in use. Can’t start script.”
If you use run script in your application, keep track of the number of call stacks that you will be using. If other processes will require call stacks, such as the Pathname or Security procedures, be sure to leave enough call stacks available.
|
We recommend that you don’t nest run script statements more than three levels deep. If you exceed this number, your application may run out of call stacks. |
One way to reduce the number of call stacks your application uses is to move functionality to a procedure script instead of using a field change script started by the run script statement.
Another possibility is to use the run script delayed statement. The run script delayed statement runs a field change script after all foreground scripts have finished. Then the first call stack is available to process the script that was started using the run script delayed statement. This is shown in the following illustration.
