Database Reference
In-Depth Information
should do and any setup necessary to make the script run properly. Plus you have a list of
people who've worked on it and can give you background or pointers. Also, the date can
help identify whether a particular business rule was in effect that made certain parts of a
script necessary. Or if you see that a script is really old, you may decide to rewrite it with
some of FileMaker's newer features. Comments don't take up much space or slow down
your scripts, so commenting scripts as you create them saves you time later. You can see a
commented script in
Figure 17-1
.
Figure 17-1. Script comments appear in bold and with a # symbol in front. The first comment tells
who created the script and when. Blank comments create white space in the script to make it easier
to read. A pair of comments talk about what the script does and the context in which it should run.
A final set of comments lists the script parameters that must be set so the script can run properly.
See page 684 for the scoop on script parameters.
TIP
There's another way to indicate what your scripts are doing: Put comments in any embedded calcu-
lations. When a script has an
If()
statement that uses a complex calculation for its condition, com-
ments in the calculation itself can demystify the calculation's purpose and the way it gets its work
done.
Importing Scripts
Some scripts are so handy that you want to reuse them in another FileMaker database, but
you don't have to recreate them from scratch. If you have access privileges that allow you to
modify scripts in the file that contains the scripts you need, you can import scripts from one
file into another.
