Just an observation, but your second question (about the frm002_PAF) deserves its own post. I won't address that question in this thread.
As to the issues you suggested in your first post, here is the way I do this.
Setup: FE/BE database, BE shared via network shared drive. FE's copied all over the place. I sometimes have to shut it down or at least make it painful for the users to come in. I sometimes have to track down users, too.
At least a partial solution is this:
I roll my own security based on knowing the user's identity by querying the domain to say "Who is this schlump?" I get back an ID that depends on the user's domain-based login (so it is harder to fake/impersonate). The name is used to look up the user in the tUSR table that contains the user's role. When the user brings up the FE and connects via my master form (a type of switchboard that never goes away), I look up the person and log their presense in an audit log (tEVT). I also update the "last login time" and "in the database" fields in tUSR. When the user logs out, I update the "in the database" field in tUSR because the master form has stayed open in the background. The form's OnClose event handles that update.
How do you know who is in the database? Do a query on the "In the Database" flags to see who is still there. You can also look at the .LDB file using IE to translate it. The workstation names will be enumerated. As it happens, when my users log in, I also store their workstation names, so it is a trivial lookup to identify them. Hint: Look at the Environment functions to identify username and workstation.
Now, here's how you shut it down. As part of the scheduled-events table (tSCHED) I can put in an event with a code that says "database will be down for maintenance" and I can put a start and stop date/time on that event. So... when an event needs to be scheduled, I have a form to add an event with a "down-time" flag, a start time, a stop time, and a description. The form enforces that the stop time MUST be in the future though the start time does not also have to be in the future.
Part A - when a user logs in via the master form, that form looks at the tSCHED table to find the earliest event with a stop time still in the future. If the time is between the start and stop times of a "down" event, the user is told "Sorry, database not available, try again after <event stop time>" - and the master form does an Application.Quit
Part B - remember that I said the master form doesn't go away? In the background, the master form runs a timer and using the OnTimer event, checks for the event with the earliest start and stop times where the stop time is still in the future. (The query isn't that complex, really). If the timer code sees that the current time is between the start and stop times for a down-time event, it immediately does a timed message box with an "OK Only" type of button layout. The OnTimer event then triggers the master form to shut down the application. You need a timed box so the user can't just refuse to acknowledge it. I do an enumeration of the "Forms" and "Reports" collections to see what open items need to be shut down, do a forced shutdown on each of them, and then shut down the app. The users never see the database navigation pane, so I have at least that much control over what they can do.
Clunky? Yes. Works? Yes. Wish it were easier? HELL yes. Lots of work to maintain the required tables, timers, and infrastructure? You know it is. But it is "the cost of doing that kind of business."
