Figure 1: Your options -- Set Variable script step dialog.

A: Congratulations on upgrading! You'll no doubt find many more gems like Set Variable in your exploration. As you now know, this script step lets you create, name, and assign value to a variable all in one step -- without requiring you to create a global field ahead of time. Before FileMaker Pro 8, when script variables were introduced, we had to use global fields to store temporary values for such things as find criteria and loop counters. The most obvious benefit of script variables is the reduction of the number of global fields created for these short-term storage purposes. Variables help cut down on the clutter in the database field list. Variables also provide a key unique capability over global fields; however, that I'll explain in a moment. First, let's review the basic syntax. Here's a snippet of script that finds all records matching the current record, and figure 1 shows the dialog for the Set Variable script step:

Set Variable [$currentPerson;
  Donations::PersonID]
Enter Find Mode []
Set Field [Donations::PersonID;
  $currentPerson]
Perform Find []

As you observed, you can assign variables with the Set Variable script step. As with fields, you have great freedom in naming the variable -- except the name must begin with either one or two dollar signs. It's the shorthand that determines whether the variable is local ($) or global ($$) in scope. Local variables are visible only in the script that set them, whereas a global variable persists after the script ends, and the value it contains can be used by any other script or calculation in the file. By using local variables, multiple scripts could be using what seems to be the same variable -- say, $counter -- but the content of each $counter would be unique to its own script. (This behavior is true even with subscripts, when one script calls another script.) Local variables evaporate when the script that created them ends; global variables disappear when the file closes.

So that's all well and good -- variables are handy and easy to maintain, because they clean up after themselves. However they also possess a particular ability that global fields don't have, with regard to file paths. Extending the example script snippet, let's say you want to save that list of found records for a single donor as a PDF of the printout. You'd likely use the Save Records as PDF script step:

Save Records as PDF [No dialog; "Donations.pdf";
  Records being browsed]

You can name the file whatever you'd like, but you must name the file manually when the script runs or hard code the name in the Output File Path dialog. If you ran this script for another donor, this step would save the file with the same name, overwriting the prior file. This limitation goes away by using script variables! Examine the following two script steps:

Set Variable [$filepath;
  Value: "Donations_" & Donations::PersonID & ".pdf"]
Save Records as PDF [No dialog; "$filepath";
  Records being browsed]

This script dynamically names the saved PDF files, embedding the (presumed unique) PersonID in the file name. You could, in short order, write a script that saves specifically named files for each donor in the database. Note that just naming the file with no additional file path information results in the file being saved to the same folder as the FileMaker Pro file that saved it -- which may not be the most desirable location. For more control, construct a file path string using relative (e.g., file:../filename) or absolute (e.g., file:/C:/foldername/filename) file path naming conventions. Use functions such as Get(DesktopPath) or Get(DocumentsPath) to easily save files to the user's desktop or documents folder, like this:

 Set Variable [$filepath;
  Value: Get(DesktopPath) & "Donations_" &
    Donations::PersonID & ".pdf"]

There are a few other things to know about script variables:

• Like a field, you can freely use variables in calculations.
• You can also create local and global variables in the Let function. This function could already set variables, but whose scope is limited to the function itself (see the FileMaker User's Guide for details on the Let function).
• Unlike global fields, you can't use variables to define relationships.
• Like global fields, in multi-user hosted databases variable values are unique to each user session. Two users could both be using the $$faveColor variable, for example, and it would hold that particular user's choice.
• Variables can hold content corresponding to FileMaker Pro's field data types: text, number, date, time, timestamp, or container. The data type of a variable is set dynamically, based on the assigned data.
• The Set Variable script step is Web compatible.