Concurrent Data Entry in Forms
We created a form using for staff to register for daily available slots. Unfortunately, when we tested the form, we did not test it for concurrent data entry. And lo and behold, when we opened the reg...
Forum Discussion
I think this problem is a little be harder than you may think. Basically you need a way to create a lock on a record to the exclusion of others that may be attempting to create a lock on the same record. In Computer Science this lock is called a mutex and it can be a difficult subject to understand and implement.
I haven't worked out all the details but you might be able to create a lock on a record (the time slot) by associating a unique ID for the record. Then all users that might want to attempt to lock that record would create record in a secondary lock table using API_AddRecord where there is a field that has the unique property set. The first API call that reaches QuickBase will successfully create the record in the second table but all other users would receive Error Code 51 (Attempting to add a non-unique value to a field marked "unique"). Now the user that successfully created the record in the secondary table can be allowed through client side logic to claim / edit the desired record in the original table and subsequently delete the record in the secondary table (so it does not grow endlessly).
I haven't worked out all the details but you might be able to create a lock on a record (the time slot) by associating a unique ID for the record. Then all users that might want to attempt to lock that record would create record in a secondary lock table using API_AddRecord where there is a field that has the unique property set. The first API call that reaches QuickBase will successfully create the record in the second table but all other users would receive Error Code 51 (Attempting to add a non-unique value to a field marked "unique"). Now the user that successfully created the record in the secondary table can be allowed through client side logic to claim / edit the desired record in the original table and subsequently delete the record in the secondary table (so it does not grow endlessly).
- This would be an elegant solution if I can do it (which sounds hard for me :) ). In the meantime, I will attempt Alex solution below. Thank you for thinking through this. I am glad to know that there wasn't any native solution ("check") I did overlook.
- I will probably create a demo of this and I think you will be stunned by how short the code is. However, I go through a process that has a lot of steps when creating a demo and I a have a few others in the pipeline and other work to do. Hang on and ping me if I don't get back to you.
- Hello, were you able to do anything about this? Thanks.
