FileMaker Extra: Portals and Record Locking

FileMaker Extra Portals and Record Locking

Record and portal rows do not lock until a user begins actively editing a field or when a script performs an Open Record/Request script step.

At the point at which a user begins actively entering data (or modifying existing data), a record lock is established until such time as the user exits the record and commits or reverts the record.

It is important to keep this behavior in mind and to understand how it applies to portals. When a record is being modified and is related to other records viewed in a portal, it and the portal itself are locked; however, other users (or the same user in a different window) can navigate to one of the related records and edit it directly.

Portal rows and related records are created when the record is committed. FileMaker treats the entire set, including the parent record and all related child records, as a single transaction. It is possible to create a new parent record, tab from field to field entering data, tab into a portal and create a few rows (including potentially entering data into fields from a grandchild record), and either commit the entire batch at once or roll back and revert the entire batch. To support such functionality, FileMaker locks the entire portal for a given record.

Record locking used to be more of an issue for both users and scripts in versions before FileMaker 7. Although FileMaker 8 doesn't do away with record lockingnor would we want it to, for maintaining data integritythe behavior you need to anticipate is far more localized than in version 6 and earlier.