< Day Day Up > |
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 > |