Shouldn't it be an error capture thing...?
The test is to attempt to edit the record... so you could do that by editing a dud field... then the error returned would return the error number... giving you the control of next step.
maybe some record open/closed calcs too?
with looping thru records or portals...
Keep in mind that a user being "in" a record, as described by Lindsay, means that the user has actually entered a field and begun editing/changing data. Unedited records, even with a user's cursor blinking away inside a field, will not register that the user is "in" that record. It's triggered by record locking, which is only on uncommited changes.
Know which user is just viewing a record is not possible AFAIK. When you consider the possibilities of list view and multiple windows, this is a logical limitation. It's even possible for multiple users to have their cursors inside the same or different fields on the same record; nothing will trigger until more than one of them tries to edit/change/add data for that record.
I build a script in some some tables to simply display a custom dialog showing how many users are logged into the current file using the function: Get ( UserCount ). This tells how many users are in the current file while it's served. Such info is useful when I know I have to go into Define Database mode on a live file. It won't return a list of names, however. You have to use the server admin tool to find out who is logged into a specific file by name, and even that won't give you any record-level info.
Lyndsay's test is the only test I know of that will return a user's name for a specific record.
Hi, I ran into an issue where a script ran and another user was in a field that was being used by the script. I would like to know this before I run the script. So I can show another department who is doing what. It is a communication problem.
I assume you are already doing this but you should be trapping for error 301 Record is in use by another user. There are other errors that could be called but that is the most common. You can’t report who locked the record but at least your script won’t break.
I asked a few years ago if we could have access to the user name of the offending party, after all without error capture on FMP does report who the user is, we just don’t have access to that info.
Pueblo Systems, Inc.
Yes... the info about the user locking a record is obviously available... as the dialog proves... so why we can't capture it is difficult to comprehend.
At least when you do the 'dud' edit test... you get the feedback before you spend time entering data. It could be in a loop so that it retries the edit until the record is available for editing or until they click a cancel button.
If at the beginning of the process of editing a log ran... you could capture the log and filter to see who is editing your record... and then the log would run again upon commit... so the log can display/calculate open records.
You could also script fields so they commit immediately once changed... limiting the time for open records.
This can all get very tricky if you have several points of access... like web, Go and FMP. Mind you, if you make only PHP access, you can manage the error but retain the data to be submitted in one window and go on with other work in another window while waiting for the record to be released.
What would be really good is if the user got a shock when they have had a record open and idle for too long.
I like the way you think, Lyndsay ...
LOL.. I'm getting more radical in my old age...
I think, Mike, it is only fair that you click my like button...
The number of times I've had to deal with stubborn users who ended up locking records had me thinking - and stating - similar things. Even to the customers!
About the script which ran... Did the script start on the record which was locked, or did it get to it as part of a process in the script.
If it starts on that record, you could test at the start of the script (by trying to edit) and escape the script with a dialog warning.
If the script is already partially executed before hitting the locked record, that not testable up front.
Have you looked at Todd Geist videos on transactions. It is a really nice way to capture errors, and revert changes back if you need to.
I also like to include an OnTimer script that gets set for a few seconds after events. So that a record is only locked for a few seconds when a field is exited or a keystroke made. You do have to be careful, though. It can be come frustrating for a user if they are trying to gather info as they are entering data and the record keeps committing on them and they have to reenter the field.
Yeah, I went to Todd's session at DevCon. Pretty cool, really. But there's a downside to the whole thing. I have one system that used to use a portal to mimic line items in a form. The users would fill out the "top part of the form" (i.e., the parent record), then start entering line items. Very intuitive, really, when you consider the notion of filling out a form.
Problems cropped up with business rules. At the customer's request, we had lots of field validations on the child records. Users would get themselves trapped by failing field validations, then not have any way of getting out of it.
Real mess until I reconfigured to allow them to commit each line item as it was created.
So Todd's technique is great, but locking the parent record also can have drawbacks under the wrong conditions.
I haven't run into users hitting a vicous circle of field validations. I would love to see an example of it.
Transaction modeling requires a different approach to certain things. Especially how you handle errors.
Oh, it's ugly.
Here's the scenario: You have validations set on the child records. The user creates and enters data on multiple child records. Since no child record has yet been committed, none of the schema-level validations triggers. Once the user is done entering records, he says, "Done!" and clicks "Print". Then, all Hades breaks loose.
The system finds that validation isn't satisfied on one or more of the related records - except the user doesn't know which one. The user gets VERY grumpy, because the validation message (ex. - "You must enter a date between 1/1/11 and 12/31/11") is correct on the record he's looking at. It's wrong on some OTHER line item that's hidden somewhere else on the portal.
Or, let's say you have multiple validations per record, and multiple records created with multiple validation violations per record. This is what we were running into. Users would create lots of "rows" - child records - by entering one field of data over and over and leaving all the other fields blank. They they would try to go back and fill in the other rows later, except they would get multiple triggering validations as soon as they tried to commit.
Admittedly, it wasn't designed very well. Nevertheless, at the time, Script Triggers weren't available to trap the Commit Record event, and I had a whole lot of three-finger exits.
In addition to all the good ideas, you do not need to change data in a record to then capture the 301 error (saying someone is in the record). Open Record/Request will produce 301 telling you that the record is in use before you attempt to write to it.
UPDATE: My apology for presuming someone might understand my cryptic response. Script might be:
Set Error Capture [ on ]
If [ Get ( LastError ) = 301 ]
... do whenever because you can't modify the record
... modify the record
Open Record/Request, besides telling you that a User has possession, will lock the record for your editing if it is available.
Message was edited by: LaRetta