3 of 3 people found this helpful
If you are using FileMaker Pro 16, check out the Get(LastExternalErrorDetail) function:
- For operations that attempt to lock records already in use, returns the name and account of the user currently editing the record.
So you could write a script to determine and capture who has the record locked.
AFAIK there is no way to programatically determine who is using a record.
There is no way to programatically "force" a user out of a record, which is a good thing: say you're entering data into a record and some huge hand grabs you and pulls you away from the keyboard, saying "You're done here." That's what programatically allowing one user to force another user out of a record would be like.
The only way to manage record locking is to plan for it to happen and program accordingly: it may be enough to start a process with "Open Record/Request" and trap for error 301. If the error happens later in a process it may be necessary to roll-back the process. It's not enough to just hope it doesn't happen.
In my experience, databases with just a couple of users rarely have record locking issues -- often the problem is caused by a record being open in multiple windows on the same computer. However as soon as you get over about 30 users you need to be expecting records to be locked and be dealing with it. Sometimes the solution can be to create a table of related records instead of editing an existing record (transactions).
EDIT: just saw David's post.
Well, this is the first feature of FM16 that really intrigues me. Most of the other feature would only be meaningful if designing a new system.
Any other hidden gem that a FM15 solution would get with 16 upgrade.
Well, this is the first feature of FM16 that really intrigues me.
The Get( LastExternalErrorDetail ) function has been around forever -- the script reference says FMP 6 or earlier. The only new behaviour may be the the ability to return the account name of the user locking the record.
Nice to know, and something I'll be adding when everybody is on 16.
I usually get a message that specifies the user locking the record and I get the option to send the user a message.
Yeah I get the same. I don't recall manually setting this up so I'm confused as to why it doesn't happen to other people.
The issue is trapping for the locked record in scripts and managing it accordingly.
Yes, If error capture is on you won't see the record locked dialog. I usually have error capture on but I will sometimes turn it off before opening a record because the ability to see who has the record locked and send them a message is valuable for users. It's good to see that Get ( LastExternalErrorDetail ) at least gives us the option to show the user who has the record locked. That would be sufficient in some circumstances, and would allow me to keep error capture on and handle as required.
Better yet is there a way to force the user out of the record.
If that were possible it would be horrible. The user may be in the middle of editing a record and may decide to revert instead of commit. If you were able to commit for him to get him out of the record he may end up with half a record or with data he did not want. If you were able to revert for him then he would lose his data.
As mentioned earlier, the solution is in providing the user with an intuitive workflow that leaves them in an open record for the shortest amount of time.