Record Locking: You cannot use this record until (FileMaker User) is finished

record locking: you cannot use this record until (FileMaker User) is finished

What is record locking? Why did my dashboard break?

While working, have you ever been thwarted by a FileMaker dialog that reads:

“David Weiner (David Weiner)” is modifying this record.  You cannot use this record until “David Weiner (David Weiner)” is finished.

Why can’t I use this record until someone is finished?

This is caused by a challenge that all database systems face called conflict resolution. What happens when two people in different places simultaneously edit the same record? Which edits win? What if I have the most recent information about something, but someone else started editing after me?

Every database system has a method for handling this, and FileMaker is no exception. FileMaker addresses this dispute by instituting a “lock” on the record. As soon as I put my cursor in a record and begin typing, FileMaker “locks” the record on my behalf. Other users can’t edit the record until I’ve committed or reverted my changes. This YouTube video does a great job of explaining FileMaker’s record locking. This blog post specifically details the hazards and benefits of FileMaker record locking.

Hazards of Record Locking

If your system has a dashboard-style layout that uses a table full of global fields, multiple people can edit those values simultaneously. However, as soon as you add a non-global field to that table, the record becomes locked when anyone edits fields on the dashboard, even global fields. It can be puzzling for users when a dashboard suddenly stops working due to record locking.

If you’re trying to edit schema in a table while another user has locked a record in that table, you will be prevented from saving your changes until the lock is released. This can occur frequently in a busy system with many users, and is annoying at best and halting at worst.

A problem occurs when a user’s cursor is in a record they’ve locked and they walk away from their computer. The locked record will be totally uneditable while they’re gone. A user with administrative credentials can kick them out of the database by using the admin console. This is annoying at best and halting at worst.

Benefits of Record Locking

First and foremost, record locking ensures data integrity by guaranteeing that the data you’re working with is the most current. In FileMaker, data is always “live,” meaning that users see updates immediately. If you are in New York editing a record, and I’m in Los Angeles looking at the same record, as soon as you hit “enter” or move out of the record, those edits are reflected on my screen immediately. While you are editing fields in that record, I am able to see the last saved version, but I’m not able to make any changes to that record while you’re editing. I also can’t see what you’re editing until the record is committed due to record locking.

This benefit is extremely useful for multi-user environments. In FileMaker, there’s never a need to manually resolve conflicts between users, because there’s no way for two users to make simultaneous and conflicting edits to a database record. Once a user is finished making changes, the next user can make changes. There’s an argument to be made that perhaps FileMaker could allow field-level locking instead of record-level locking, which would allow people to edit portions of a record without conflicting, but there may be technical or practical challenges involved that currently put this solution out of reach.

Conclusion

Record locking provides instant, accurate data for multi-user environments. While the message “You cannot use this record until “User (User)” is finished” can be frustrating, the benefits of record locking outweigh the hazards.

If you have further questions about record locking, feel free to contact us!


*This article was originally written for AppWorks, which has since joined Direct Impact Solutions. This article is intended for informative purposes only. To the best of our knowledge, this information is accurate as of the date of publication.