Automating tasks with scripts
Scripts can do simple tasks like setting print orientation or complex tasks like preparing a customized mailing to each client.
For example, you could define a complex set of tasks that creates a thank you email to clients in your Clients database who have made purchases in the last week. The script composes an email tailored to each client. The script switches to Preview mode and pauses so you can see what the message looks like before it is sent. The whole task is initiated by clicking a button on the Sales Entry layout.
You build scripts by selecting from a list of FileMaker Pro commands, called
script steps, specifying options (if necessary), and arranging the steps in the correct order to perform the task.
Scripts normally run on the
client, but you may want to run some scripts on FileMaker Server to improve performance or to automatically run on a schedule. See
About running scripts on FileMaker Server.
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.
•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. See
Windows script steps.
Note Scripts performed in Layout mode automatically switch to Browse mode before executing.
•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.
•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 too 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.
•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
Creating and editing 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 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.
Related topics