Is there a common method to deal with a user leaving the cursor in a field and walking away, locking the record from other users? I recall that there was some way I'd deal with this years ago, but don't remember it. What's the state of the art?
No change, no really good way.
The server can disconnect a client on Idle.
An OnTimerScript--which can be periodically reset from script triggers on the layout if the user is actively working with the layout, can commit the record.
Both can leave a record incomplete with potential problems with your data as a result.
Another option is to use a layout with global fields for editing the data. Scripts load the globals for editing and a "save" script copies the data back to the original fields. This doesn't lock the record at all, which can be either a good or very bad thing depending on how you set this up.
What I need is a script trigger on the chair in front of the computer that commits the record when the user stands up! Some version of your first idea is what I had in mind, and the second one is more than I need. Often, I'm both users... I enter customer information at the front desk, then go out to the shop where I enter vehicle information only to find that I didn't press "enter" up front... can't find good employees these days...
MBS FileMaker Plugin can trigger a script when the user is idle for some time.
We use that often to exit a field, commit or rollback changes in current record or logging people off.
Monkeybread Software - MBS FileMaker Plugin: Schedule.StartScriptOnIdle
oooo! have a wrist band that pings the database and if it's out of range, the record is committed.
does anyone know what happens to the record if the computer goes to sleep after a time limit? I know we want this "Off" on hosting servers, but on the desktop/laptops/iPads.
Does the record commit when the user is 'bumped' by server timeout?
None of these are great options but -
If it works for your solution you could also edit a particular field through a dialogue box because a dialogue doesn't lock the record.
Or... you could have the user edit globals and then commit with a save button, that way the record is never left locked
Or... you could seperate the data into separate tables so that less of the data is locked at once.
Just had an idea:
Add a CommitRequest table and link a foreign key field to the primary key field of the table where you want to force a commit. Enable "Allow Creation" for this new table. Add a second field PID, to this table.
When you want to commit a record on another computer, you click a button that does this:
Set Field [ CommitRequest::PID ; Get ( PersistentID ) ]
Set Up an InstallOnTimer Script OnLayoutEnter that checks for a related record in this table with a different persistent ID. If one is found, it deletes the related record and commits the record.
To to avoid committing a record in active use, this script can use a popover or new window to display a message and a button. If the button is not clicked after a pause of so many seconds, the record is committed.
Creative idea... but my layout might be too complicated for such a scheme. My Repair Order layout has few fields from the Repair Order table.,. mostly totals... calculations. The layout has customer information from the Customer table, vehicle information from the Vehicle table, line items in a portal from the RO Line Item table, Payments in another portal from the Payment table, and all are modifiable.
I was imagining using some of the many Get functions via an InstallOnTimer script set to run every minute or so. It can look at the state of the record, Get(RecordOpenState), the name of the active field, and the contents of the active field, and can compare what if finds with earlier runs before deciding to commit the record, or displaying a dialog. Haven't tested this yet, but seems fairly straight forward. One thought I had is that it would have to actually look at the contents of a field, not just the fact that the same field has been active for awhile because I have a couple of large text field that might have paragraphs of descriptions of the job. I might have this field active for quite a while when filling it in.
I checked out the plugin, which looks interesting, but I prefer to stay native if possible.
Also, one problem that most of you can probably relate to is how easily one can spend hours figuring out cool puzzles when the main job isn't done yet! That's where I am... I need to get the main functionality done so I can actually USE this thing!
That doesn't mean that I won't do it anyway... right after I replace the exhaust manifold on the jeep sitting next to me...
Your layout design should not complicate this all that much. It's the current layout record--the parent record that you lock and that you then request be committed. Committing that parent record should also commit the related records that might be open.
The actual scripting would be pretty simple.
Oh, I see what you mean... didn't get that you're actually sending a message to the other computer to commit. It makes my brain hurt a bit, and now I have another thing to play with!
no need for an intimer script -that record created you mentioned can be opened in a hidden window and has an OnRecordLoad trigger associated - so the other user who wants to evoke a commit on the blocking user's computer - finds that record as you mentioned and deletes it - the OnRecordLoad trigger executes and commits the record...
I had forgotten about the delete record trick! There are some details to manage carefully but that definitely sounds better than OnTimer.
was a long time ago when first suggested here - 2013 ..
Trying to visualize... so each computer would have a script that sets up the hidden window and sets it to the correct record? Triggered when... the layout is entered maybe?
beverly schreef: oooo! have a wrist band that pings the database and if it's out of range, the record is committed. does anyone know what happens to the record if the computer goes to sleep after a time limit? I know we want this "Off" on hosting servers, but on the desktop/laptops/iPads. Does the record commit when the user is 'bumped' by server timeout?beverly
According to Filemaker documentation this applied to FMS with FM Go. I assume it is the same with a client computer using FMP, although I'm not sure if the same applies to shared solutions.
FileMaker Server handles record modification differently depending on the circumstances.
While a record is being edited, either by a user or a script:
If the iOS device… The hosted record will be…
Loses network connection Not modified, locked*
Closes the file or window (user action) Modified, not locked
Hibernates FileMaker Go Not modified, locked*
*The locked record will be released when FileMaker Server determines that the user is no
longer a client of the hosted file.
Accordingly record lock will be released at the moment FMS realizes the user is no longer there, which will also happen when a connected computer goes to sleep.
Yes, I know about FMGo looking at FMS. I cannot seem to find documentation on FMP to FMS.
Retrieving data ...