Multi users environment - forced log out / reminders to log out

HelpMoses76

Member
Local time
Yesterday, 23:19
Joined
Sep 17, 2020
Messages
45
Is it possible to

1) Find out which users are currently in the database ( which is on a shared drive)
2) Display a message to everyone at 315 pm each day to exit the database
3) Log users out after a certain amount of inactivity ?

I do not know if this is even possible in ms access vba

Thanks.
 
This seems to come up a lot and there are many threads on AWF about it.

Here is something I just happened to do recently.

1) create table to store IdleTimeReset info - mostly containing Username and DateLastActive
2) create function to ResetLastActive by inserting a new record with username & now() into table IdleTimeReset
3) create function to see how long someone has been "idle", by doing a datediff (minutes) on the dmax (DateLastActive,IdleTimeReset, where=their username)
4) call the #2 function in the click events of anything they can click on, in my case I only had about 15 and it was easy
5) call the #3 function in a form timer event about every minute or so, if their idle time > what minutes then exit app. Or you can display a form with a countdown....and an option to reset.

That's just one idea. People have much more sophisticated API's to actually figure out idle time, but I don't use them.

Another option is to create a windows task on each person's computer (why? because task scheduler has a built in "# of minutes idle" trigger), when it gets triggered run a simple vbscript to GetObject their access app and exit it.

Another option that I always have in every datatabase is a form timer to read a text file on the network...if the textfile has a 0, all is well. if it has a 1, their database will close. It's a "force out" that I use when necessary.
 
It is possible but takes some work

In order,...

(1) is possible, and most easily done if you have an opening form that, after getting the username, writes an entry in a table with the date/time, the username, and either nothing else or maybe the words "LOGGED IN" - and if you really wanted to get pushy, log the user's computername. Then this opening form (which could be your switchboard) will stay open for the life of the session. If you have a separate switchboard form, either that form can take over session monitoring, or the opening form can minimize and continue monitoring.

When the user logs out, you can make another entry with the date/time, username, computername, and "LOGGED OUT." The catch comes in that if the user's computer crashes or is abnormally rebooted or has a network failure, you have a "dangling session." If they log back in, you can ignore the previous "dangling" session. At any time, you can check the login records to find all users for whom the last record is "LOGGED IN"; i.e. there is no later "LOGGED OUT" record.

(2) IF you had that opening form that stays open, you can put a timer in it for some relatively comfortable interval and have it check every so often for the time of day. You can have the timer routine wake up every five or ten minutes and when 3:15 would be the next awakening, pop up a modal dialog box reminding the user to leave. It is relatively easy to compute the interval from NOW() to a convenient time like the beginning of the next hour or something like that, so from that point forward, you would by synchronized to the time of day.

(3) If you have that opening form running with a timer, one thing you can do is have the timer routine check for inactivity. BUT this gets trickier because if someone is just waiting on a long-running process in some kind of loop, maybe you don't want to interrupt that. Maybe you do. Hard to tell either way. BUT what I did is put a globally accessible variable in the front-end file that recorded the last time any form or report was opened and the last time any button was clicked, A couple of other actions also triggered this time-stamp of "last activity." Then the timer could compare that time to the time of day to determine a difference. In my case, I wanted the difference in seconds. Then if they exceeded the idle-time limit, I initiated the forced shutdown. I gave them 20 minutes. I also had a "notification" box on all of my forms where I could put up an "IDLE WARNING" message in red bold letters with a yellow background. AND I could make the terminals beep.

The trick here is that you should verify that nothing is left open. The CurrentDB.Recordsets collection lists all open records at the moment. If you close all of those then an Application.Quit should remove the session. (Just be sure to log a "LOGGED OUT" (or "FORCED OUT") entry in the login history table if you do this. You have to do this from the FRONT END because the recordset data is recorded there. That is where the work space resides, not the shared back end.
 
Why would you want them to log out mid-afternoon? Scheduled maintenance or batch processing should be conducted during off-peak hours.
 
Pat, I can't speak for the O.P. but for me, 3:15 PM was 15 minutes into 2nd shift. Navy hours aren't like regular 9-to-5 jobs. One reason why I was so deliriously happy to retire. Getting up before 6 AM to be at the office by 7 got old VERY quickly.
 
The simple answer is yes to all three questions though I would also do maintenance work in off peak times e.g. 03:00.
By ensuring that users quit the database after a specified period of inactivity e.g. 20 minutes, you can then run maintenance as a scheduled task at a convenient time.
 
Are we really trying to tell an OP about how their end users/employees work shifts are structured??
"I'm sorry", but I'll have to disagree with that as a whole!

@HelpMoses76 : Feel free to lead your people as you see fit, for the love of God! :)
 
No, we're trying to emphasize that database changes should be made at off-peak times. For this user 3:15 might be off-peak. Who knows?
 

Users who are viewing this thread

Back
Top Bottom