Another User On The Record

["... you mean these fans?"]

I have a customer that keeps seeing this type of message, "This Person (TP)" is modifying this record.  You cannot use this record until "This Person (TP)" is finished".

I continue to tell them that "This Person" must be on the record while they swear that "This Person" is not.  So I say that this person must have exited the application improperly were the server still see them on the record in question.

I just received this message from a recent communication with me and the client at 9 o'clock in the evening, nobody was on the record other than me and the customer yet we got this message.  The person the message was referencing was logged into the server but had left the building hours ago.

It was impossible for this person to be on the record in question ... they had left the building.  Yet FileMaker server says ... "This Person (TP)" is on the record ????

Now the record in question we had just created ourselves  minutes ago.  So the person in questions ( in the error Message ) could not have been on the record, again they left the building hrs ago.

So I start thinking "How can FileMaker Server" lock out a record based on a person logged into the server yet not in the building for hours ?

How do I begin to trouble shoot this issues ?

This message error is a regular complaint by the customer ... ?

 

Thank you.

 

 

Edited March 2, 2018 by Mr. Ignoramus

[Josh Ormond]

Do you have any PSOS sessions running? Look at the server and see if there is something running. Could also be a scheduled script if the users credentials were used. 

["... you mean these fans?"]

Hi Josh,

Sorry for the delay, had to wait for the 'Lock' record to happen again which it just did.  Called the server administrator and he could not see any PSOS session running ??

The only scheduled script is a daily back up and a hourly back up.  Every User signs in and we use their ID with every record creation.

Is there another way I could start to log my PSOS script ... Start and End and the scripts within the PSOS that are called, would that be possible ?

Thank you.

Edited March 6, 2018 by Mr. Ignoramus

[IdealData]

Mr I.

Apart from the obvious record lock, where a user is actually editing the record, there are other scenarios:

1. A backup is running - FMS will lock the database during the backup. You have nightly and hourly backups running?
2. As Josh says, a script is running and has locked the record.
3. A developer is editing the layout!! - Yes, it does report the record is locked if you are editing the layout.
4. A developer is editing the database schema - this locks the database/table when making changes.
5. If a user 'crashes' out then FMS will release the record after 2 minutes.

If you run a script via PSOS that edits a record then you need to COMMIT the record before the script ends. Whilst PSOS is 'like' an FM Client I discovered that running off the end of the script without declaring close window/exit app/commit record leaves the record locked. Rule 5 (above) resolves the issue eventually. This is easily overlooked and could be very much your case.

And;

Quote

Now the record in question we had just created ourselves  minutes ago.

If this user has a second window open on the same record, and the record has not been committed in the first window then this will also produce as lock but there is a different message if that's the case.

[IdealData]

There is a further scenario..

1. If you are editing a record that has a portal then all the portal rows become locked
2. If you editing a portal row then the parent record is locked, and rule 1 applies again

The EXCEPTION to this is when editing the RELATED records from a different layout with a different context. Even if the context is the same as the PORTAL then you can still edit the related records when the parent record is locked.

You cannot edit related records in either layout if the related record is actually locked directly.