FileMaker Extra: Portals and Record Locking

 <  Day Day Up  >  

graphics/new_icon.jpg

Record locking behaviors have changed with FileMaker Pro 7 from prior versions. 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 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 Pro locks the entire portal for a given record.

Record locking used to be more of an issue for both users and scripts in prior versions of FileMaker Pro. Although this new version doesn't do away with record locking ”nor would we want it to for maintaining data integrity ”the behavior you need to anticipate is far more localized.

 <  Day Day Up  >  


QUE CORPORATION - Using Filemaker pro X
QUE CORPORATION - Using Filemaker pro X
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 494

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net