Just to state the obvious, developers working on the live file need to be very, very careful in what they do.
You could set up a table and a script performed by the OnFirstWindowOpen trigger. The script can create or update a record in the table with a user's account name each time they open the file. A similar process can log them out when the file is closed, but this doesn't work in event of a crash or force quit.
Agreed. And I stated as much to my superiors. But this is the reality I am in, so it is what it is.
That's a good Idea. I'll give that a go.
check out thee fmsadmin server side CLI options.
The relative "risk" to other users and/or the file itself varies with the type of change being made:
Layout, script, value list changes.
These usually are quite safe to do, but can catch a user "between chairs" if the interface suddenly changes on them in the middle of a task that they are completing. Keeping such changes incremental and having good communication with your users helps a lot with keeping these changes happening smoothly.
Relationship/table occurrence changes
Adding/changing relationships, restructuring the relationships graph.
The same "caught between chairs" issue applies, but now, there's a very small added risk that a glitch might happen and not be noticed that takes place right when you commit the change back to the hosted file which might introduce latent file corruption.
Adding/changing field definitions
I consider these much more risky. Not only do all of the above concern applies, but other users are locked out of a table while the changes made to it are applied once you exit Manage | Database by clicking OK. I haven't tried it since FMP 10, but it used to be that simply opening the calculation dialog to inspect an auto-enter calculation locked everybody else out of the field's table until you closed that dialog.
Adding/changing field definitions
One correction: If there are no auto-incrementing fields, then users are not locked out while the developer is making changes.
On the contrary, they are indeed locked out once you click OK during the time that the changes get saved back into the hosted file.
On the flip side a developer can be locked from making changes to the schema if a user is editing a field. Live editing while in use should be done with caution.
1 of 1 people found this helpful
I use this on my clients computers a lot to see how is online:
Basically it uses the same technique that MBS one does that Christian links to, but it uses the free BaseElements plugin. Both work just fine.
I've created a Login Table and when a user opens the file, the on first window open script creates a login record which contains lots of information. When they quit, the record is marked logged out. IF the server is closed and reopened then all records are marked as logged out if needed.
It would be easy to perform a find on that table and display the results in a report in a Card or Dialog or Floating window... etc.
I will give this a try tomorrow if I can get permission from the higher ups to install the BE plugin on the client's server.
Thanks everyone for great ideas!
The problem with a Login table is that people get disconnected and when that happens, the On Last Window Close script trigger doesn't run and it looks like people have been logged in for a long time when they haven't. I log users coming and going, but if I want to see who is logged on now, I use the plugin and FMSADMIN command to list the users because I know it will always be accurate.
fmsadmin list clients does not give you the FM account names of the users. It is useful, but how useful?
You are correct about the disconnects.
However, the Login table for me is still usefull as I can use it to list a report of all logins by privilege set and account name and their locations, etc.
It is especially useful for determining if a password is being shared and where the clients are logging in from (or is that clients are logging in from where?)
I caught a former developer logging in using the owner and 2nd in commands passwords (he had handed them out and never required a change, which I did).
Also using 24U's Toolbox I can get the users Client IP Address and Client IP Name which might be helpful in determining if someone is going to a competitors office and sharing our price list and client list, etc.