You can trust that FileMaker is already locking appropriately. Do a test ... open two windows to the same Table Occurrence. Click into a field on one window and start to edit the entry. Then try to edit the same record from the second window.
As soon as you enter a field FileMaker obtains and enforces an optimistic record lock.
If the FM built in record lock does not suffice for your needs then you should implement a transactional method of editing a record.
Might help to be accurate.
Clicking in a field does NOT lock a record.
Beginning to edit the record does that.
use a OnRecordCommit Trigger. The trigger then can exit with True or Empty when the requirements you want for committing are met otherwise you can Exit ( 0 ) as false and it will cause an Error 20 on commit you can trap for or even give feedback to the user.
this trigger works within the context of the layout where it is installed and not on record level.
you can even create a transactional model over related records if on the same layout you are committing is a portal showing the involved related records ..
Yes. I just worded it a little wrong.
This looks great. However a little depressing on the the complexity that one has to go to for a simple need.
FileMaker please add script command: LockRecord(On) with an Off toggle with some control around the ON if a user exits a record without saving changes.
there is a script step Open Record Command. The toggle part i don't understand. what shall it do?
The Colibri file is interesting but it uses a lot of stacked fields and stacked objects. That adds maintenance complexity and is also not compatible with WebDirect.
The Open Record command does not keep the record locked (e.g click outside a filed on the layout).. So a new command such as LockRecord (On) would lock the record for no editing expect by the user locking it until it is released. It is released either with a script step LockRecord (Off) or by leaving the record to another portal or another record or another table. When the latter happens, the record is committed or there could an optional dialog box that asked to compit or not.
I agree - I do not want that level of complexity. Still trying to find other approaches......
You really need to be careful with this concept. Yes, you can lock records to prevent other users from "jumping in" while editing is in place. But if you do, you have to make sure you plan for all the other contingencies that can occur:
1) User walks away from the keyboard and leaves the record open.
2) User goes home for the day and doesn't close the database.
3) User suffers a network or computer failure and disrupts his connection to FMS.
4) Administrator needs to close the database for maintenance.
5) Administrator needs to reboot the server.
FileMaker Server will not be able to close the database without forcing it down if a user leaves a record open and walks away (or ignores the server message to close the database). Your trap for record lock will prevent it. Any open record will, at a minimum, prevent other users from editing it (which is why you're here in the first place). But if any of the other scenarios should happen, you can suffer data loss or even record or database corruption.
To implement some sort of toggle that would leave records open is even more hazardous. If something prevented the toggle from being reset (such as a developer, say, forgetting), you're in a quite unstable condition.
Again, you can do this if you like, if the business rules need it. But it should be carefully thought through and planned.
"The Open Record command does not keep the record locked (e.g click outside a filed on the layout).."
But the On Record Commit script trigger DOES handle this.
You don't need to wait for FileMaker to develop a new version or new feature.
There are existing tools and features to manage this; and like Mike says: it isn't simple.
Your notion of a simple solution may be appealing but it just demonstrates that you have not thought about the issues thoroughly.
When this thread was new, I downloaded the Colibrisolutions demo. Unfortunately I did not record the admin account and password or save a pdf of the article. Does anyone know the account and password for the demo file?
I'm considering using this approach for a current project and would like to review the file.
Thanks very much
Reply sent by PM.