I'll start by defining record locking. Record locking occurs when two Guests try to access the same record at the same time. In FileMaker Pro 6 and older versions, a Guest could take control of a record simply by clicking into a field. Subsequent Guests attempting to access the same record receive a message that someone else is modifying the record. The record will remain locked until the first user releases the lock by exiting all fields. Exiting all fields could occur by typing the Enter key on the keypad, clicking outside the fields, changing records, or changing layouts, just to name a few. The only difference with FileMaker Pro 7 and newer versions is record locking doesn't occur until a Guest starts modifying a record. In other words, someone has to start typing into a field on the record.

Now that you understand record locking, the next step is to learn how to test for record locking without setting up a Host computer, copying your solution to the Host hard drive, and sharing it via FileMaker Server. This might not seem so difficult until you realize you have to copy a new version of the solution to the Host each time you want to test a new version of the solution. An easier approach, and the only approach if you only have one computer for development, is to open your solution in regular FileMaker Pro and turn on sharing. You'll find the FileMaker Network menu choice underneath the Sharing sub-menu under the File menu. When the resulting dialog appears, turn on network sharing and make sure the file you are testing allows access by all users.

After you have file sharing enabled, the same computer acts as Host and Guest. Just choose Open Remote from the File menu. In the resulting dialog, locate your computer under local hosts. Open the solution you want to test for record locking and a second occurrence of your file appears, using the same name in the title appended with "-2" and the name of your host. Now you're ready to test record locking. In either window, click into a record and begin typing. Without exiting the record, switch to the second window and attempt to modify the same record. You'll receive an error message telling you it's being modified.

The standard error message FileMaker Pro generates when two Guests attempt to manually modify the same record works fine. Only when you incorporate scripting into your solution does record locking require your supervision. Any time a script attempts to modify a field on a record, such as what occurs with Set Field, Insert Calculated Result, and many other script steps, you must make sure the current Guest has control of the record or else the record may not be modified. Rather than trying to modify the record and then test for an error, you're better off trying to gain control of the record without modifying it using the Open Record/Request script step. For instance, the following script shows the basic construct for a record-locking-aware script:

Set Error Capture [On]
Open Record/Request
If [Get(LastError) = 301]
   Show Custom Dialog ["Record Locked"; "This record is locked!"]
Else
   #Place any script steps here you want to occur if the record is open
End If

Briefly, the Set Error Capture script step hides any error message dialog that might appear, such as the record-locking error. The Open Record/Request script attempts to gain control of the record. If the record is locked (being modified by another Guest), an error of 301 will result. If no error occurs, the script locks the record for the current Guest and can safely modify the record. As an aside, you can release a locked record using the Commit Record/Request script step.

Testing whether the current record is locked is simple, but the task gets significantly more complex when attempting to modify multiple records. For example, the Replace Field Contents script step or a record looping script attempt to modify multiple records in succession. If you have a few Guests on the network, chances are the modifications will occur without a hitch. When you start to add more users, the chances that one or more records are locked increases.

So, what can you do in this record-locking scenario? There are complicated transaction techniques you can employ, but I like to tailor the solution to the need. For instance, say you want to mark all the records in the found set so you can search for the marker and reconstitute your found set at a later date. Of course, this process could cause record locking on more than one record, which you could attempt to track. Instead of writing a value to the records, grab the serial number from each record. Reading a value from a record doesn't require it to be unlocked. In this way, you can gather all the serial numbers and store them in a return-separated list. To restore your found set, simply use the serial numbers in a multi-key relationship along with the Go to Related Record script step. Although this is a brief overview of the technique, you get the idea. For every record-locking scenario, there is usually an alternative approach.