[color:red]FileMaker 9 Windows - sharing with FM Network:

How do others control the number of users who can be editing the same record? Get(UserCount) will show how many users are accessing the file, but not the specific record. I want to stop 2 users competing to edit an individual record.

Thanks for your help.

Hi, well what do you mean exactly. Two users should not be able to edit the same record at the same because FileMaker locks the record when it is active. Once the first user commits the record, the second user can edit it.

Yes that's true. But say you have a database of customers. One user could be changing something and it will be changing on other screens. This particularly becomes an issue if changes are being made with a script from one user while the other user is viewing the same record. Instead of being a stable environment it will be changing before their eyes. It would be easier to manage if a user was unable to edit the record until another user was finished?

Edited March 15, 200817 yr by Guest
typo

When another user has finished viewing a record?

What would the practical purpose be of locking everyone out from editing it anyone is viewing the record. Lets take this to an environment where there are 200 users. It would be really annoying for all 199 other users to be locked out from viewing the record when one person is editing it.

That's true. But it's more annoying when one of the 200 users runs a script that operates on the record and part of it's function is blocked because someone else had the record open.

I'd just like to show that another user is already in the record. The second user can still view it, but at least they are aware.

I assume that others do not do this?

Check out the Get (RecordOpenState) function?

I assume that others do not do this?

You assume wrong, Tony.

The conventional method to confirm that a record is available for editing within a script is to set error capture, open the record and then check the result code using the Get(LastError) function, e.g. along the lines of the following:

Set Error Capture [On]

Open Record/Request

If [ GetLastError = 301 ]

# The record is being edited by another user...

...etc.

Code of this type (and variations on it) is a standard part of the error handling procedure that should be in every script that edits records in a multi-user solution.

BTW, since the script is (presumably) about to edit the record, it is frequently quicker (and just as effective) to put the edit attempt up front (after setting error capture on) and trap for record locking afterwards. Both methods are valid. :)