Concurrency (brought this over from my term of the day blog)
CLASS: Database Term
VERSION: All Current Versions
This term isn’t FileMaker exclusive, in fact it is used more within interactions with database engines of other types. However, as FileMaker becomes more powerful and flexible, terms used in other database engines apply more and more to advanced FileMaker design.
The term concurrency can be closed related to the FileMaker term of record locking. It applies to what happens when two users are trying to modify the same record at the same time. It can also apply to a situation where a user (or one of the users open windows) is within a field on a record and some other user (or even the same user in a different window) try to modify that same record.
In most cases, FileMaker will bark at the user that is trying to modify the record the other user was within first. When the other user entered the record, it became locked to that user. This is because two users cannot modify the same record at the same time. In a multiple window setting, it is possible for me to lock a record in one window, try to modify the same record in another window and cannot do it. The first window of mine locked me out of modifying that same record in another window.
However, the entire situation takes a bit of a flip if the other user is actually a FileMaker script that is trying to update records in a batch. If a script has Set Error Capture ON, there will be no notice of the record locking and the locked record will remain untouched, as all the other records in the batch are updated.
This dovetails into the other popular term of “The ACID test”, for handling what transpires in the case of concurrency issues.