Planning a script
The more time you spend planning your script, the more likely that it will accomplish what you want. As you plan, ask yourself these questions:
 •
Can you separate the task into smaller tasks? You can define sub-scripts for each small task, and then define a script that performs the sub-scripts. It's easier to design and test several small scripts than one complex one. You can also reuse sub-scripts in other areas. (Use Perform Script script step to perform a sub-script inside another script.)
 •
What script steps should be executed under what conditions? Should every script step always be executed? Should some be executed a number of times until a certain condition is met? Should the script call other scripts and sub-scripts? You can control the progression of the script in a number of different ways. See Control script steps for more information on creating scripts with conditional steps.
 •
Do you want the script to run in a particular layout? Because scripts are defined at the file level and can be called from any layout, you should make sure the script will operate in the layout or layouts you expect. Use the Go to Layout script step to change layouts.
 •
Should the script work on all records in the database, the current found set, or a specific set of records? (Use the Found Sets script steps to include only the records that you want to work with in the found set.)
 •
Is all the data you need in one database file, or will the script operate on more than one file? If you're using multiple files, which ones should the script open? In which file should the script(s) be defined? In most cases a script should be defined in the same file as the data it is processing. Database solutions with more than one file may need separate scripts in each file, depending on the complexity of the task you are trying to script.
 •
With which record should the script start? For example, when using the Loop script step, you must decide whether the loop starts at the first or last record, a specific record, or the current record in the found set. (Use the Go to Record/Request/Page script step, Go to Related Record script step, or Go to Portal Row script step to specify a starting record. If you don't include a navigation script step to determine the current record, the loop begins with the record that's current when the script is performed.)
 •
Which window do you want to use? A script is initially attached to a specific window, which may be in the background. The script remains on that window until a scripted action switches to another window. For example, use the Select Window script step to specify a different window. If the specified window is not available, the script switches to the foreground window of the file. When you pause a script, the associated window becomes the foreground window if it is available.
 •
Should the script switch among modes? A script can be run from Browse, Find, Layout, or Preview modes. Make sure your script is in the proper mode before it acts upon something. For example, use the Enter Browse Mode script step to modify data in fields and records, and use the Enter Find Mode script step to set up or perform a find request.
Note  Scripts performed in Layout mode automatically switch to Browse mode before executing.
 •
Which fields and layouts will the script need? Some steps (such as the Go to Field script step and the Insert Text script step) require a field to be on the current layout, while others (such as the Set Field script step) don’t. Either use the Go to Layout script step to switch to a layout that has the fields your script requires, or place the fields on the gray area to the right of the layout to make the fields available for script steps but not to users.
 •
Should the records be processed in a certain order? Decide among the current sort order, a specified sort order, or unsorted (the order in which the records were created). Use the Sort Records script step or the Unsort Records script step before entering a loop to order your records properly before processing them.
 •
How should the script advance through multiple fields or records? (Use the Go to Record/Request/Page script step, the Loop script step, the Exit Loop If script step and the End Loop script step to control multiple field or record processing).
 •
When should the script finish? After all script steps have run? After a specified condition has been met? (Use the If script step, the Else If script step, and the Else script step to perform a task such as the Exit Script script step when the script reaches a specified condition.)
 •
Should users be able to stop the script while it is running? Does the script contain a process that could result in incomplete or incorrect data if the script finishes to soon? Use the Allow User Abort script step to control if users can stop a script.
 •
How will you test your script? Use the Pause/Resume Script script step to pause at predefined points in your script. Save a copy of your database, and then define and test your script in it to preserve the original data.
Note  If you are using FileMaker Pro Advanced, you can use the Script Debugger to test and troubleshoot your scripts.
 •
How will you handle error conditions (such as an empty found set)? You can capture the last error condition reported by FileMaker Pro by using the Get(LastError) function. Use this function and the If script step, the Else If script step, and the Else script step to create scripts that react gracefully to user errors or unexpected results. For even greater control, use the Set Error Capture script step to suppress the error alerts that FileMaker Pro normally displays in these situations, and replace them with your own using the Show Custom Dialog script step.
 •
Should all users be allowed to perform all scripts? Use privilege sets to control users’ access to scripting. Through the use of privilege sets, users can be allowed to execute or modify individual scripts, no scripts, or all scripts. You can also set the default permission for each privileges set for any future new scripts that are defined in the file. Setting a script to run with full access privileges will allow the script to do things on behalf of the user that may not be normally allowed by their assigned privileges. See Managing privilege sets.
 •
How will users perform the script? You need to either create a button to perform the script or specify that the script be added to the Scripts menu. Scripts can also be run from the Script Workspace window or when a script trigger is activated. For example, you can use the OnFirstWindowOpen script trigger to run a script when the database opens.
Once you've considered these questions, you're ready to manage scripts in your database. See Creating and editing scripts.
Was this topic helpful? Send feedback.