Database Reference
In-Depth Information
FREQUENTLY ASKED QUESTION: WHY OPEN A RECORD?
Why would I ever use the
Open Record/Request
step? Doesn't FileMaker automatically lock a re-
cord as soon as my script starts editing it?
For simple scripts, this step is almost always unnecessary. FileMaker does, indeed, do the right
thing. But as you'll learn in
Chapter 19
,
you can set up your FileMaker database so multiple people
can use it at the same time, each on her own computer. When you set up FileMaker this way, lots of
interesting things can start happening.
For example, a record can change while you're looking at it. Suppose a new area code is added in
your area, and you write a script that looks at the phone number and decides, based on its exchange
code, whether or not to change the area code. The script might look like this:
If [ Exchange Code = 555 or Exchange Code
= 377 ]
Set Field [ Area Code, "602"]
End If
You probably find this hard to believe, but technically, someone could change the Exchange Code
field after the
If
step runs but before the
Set Field
happens. (Remember that other people are edit-
ing records on other computers, so they're free to make changes while the script is running on your
computer.) If this scenario happens, you end up assigning the customer an incorrect phone number.
To fix this, you need to lock the record before you start looking at it:
Open Record/Request
If [ Exchange Code = 555 or Exchange Code
= 377 ]
Set Field [ Area Code, "602"]
Commit Records/Requests [No Dialog]
Else
Revert Record/Request [No Dialog]
End If
Now nobody else can edit the Exchange Code field because the record is locked. In general, if many
people use your database, then you should open a record before you start looking at it in a script.
This technique can be particularly useful if your script needs to deal with groups of records, any one
of which might already be open by another user or might be opened while your script is running. In
that case, loop through your working found set and open each record in turn. Then you can either
process the group of records or take some other action, like canceling, if the script finds that one or
more of the records can't be opened.
This script reverts the record when it didn't make any changes. FileMaker does this reverting for
two reasons. First, committing a record means saving the data, and that's unnecessary here. Second,
suppose a field has had validation turned on since this record was created. It's possible that this un-
modified record has now-invalid data. If you try to commit this data back, then you get a validation
