Batch file that kicks everyone out of access database
- Thread starter bugsy
- Start date
- Local time
- Yesterday, 21:47
- Joined
- Feb 28, 2001
- Messages
- 30,567
Well, it COULD exist... but it would take something beyond the batch job by itself.
In general, you cannot just kick everyone out. What you have to do is persuade each copy of Access to exit as gracefully (or not) as possible.
Search this forum for "Forcing Users to Exit" and phrases of that genre. Here's the overview of how you would do this.
1. You have to disable the F11 and Shift methods of bypassing normal Access startup because you need to create a Splash screen or startup screen that never dies. So search the forum for how to prevent users from bypassing startup forms.
2. The startup form or splash form CANNOT EXIT. But it can minimize itself, hide itself, and sit behind the scenes with a timer running on the form.
3. The form's .Timer property can be set for cycling once ever 60,000 msec = 1 minute. When the OnTimer event triggers, check for the pre-defined exit condition (see #5 below.) If the event code finds the condition, it executes a DoCmd.Quit - and keeps on doing so until the application exits. WARNING: This means that if you have "Cancel" returns on some events, you have a way of knowing that it is time to trigger and .UnDo and get the heck out of there. So there is some coordination.
4. The batch job needs to use a command-line feature of Access (see the Help files for Access Command Line options) that runs a macro. The macro should take some action that sets up your exit condition. For instance, it could run an Append query or do some sort of RunCode to muck around with a table's contents. The macro itself must ALSO do a QUIT as its last action, to release the database from the batch job, too. Otherwise it will hang open and be "the database that can never die...." (Sounds like an old Hollywood B movie of the 50's.)
SIDE NOTE: You CANNOT use a "global" variable in a general module's declaration area to do this BECAUSE variables, no matter HOW global or public they are, remain private to your workspace - because that is where they are instantiated. ONLY A RECORDSET can be as "global" as you need for this function.
5. The exit condition might be something simple, like a table with only zero or one records and only two fields - one of which is a non-autonumber PK and the other is a string. If you populate the table with a record that says, <#1, "Force these idiots out of MY database"> (or something gentler, if you wish), then the OnTimer event can do a DLookup of record #1. If it finds the keywords you choose, it forces the exit.
6. Presumably, you would do this to force database maintenance. When you do so, you must remember to reset the record, or take some other action that deletes or invalidates or otherwise prevents the record from forcing your exit, too.
7. To prevent others from futzing around with this table, make your chosen administrator account the table's owner and deny Write, Insert, Update, Append, or any other form of modification to all non-admin users. You would therefore need to implement Workgroup Security to get there from here.
Everything I've mentioned in every talking point can be Searched in this forum. You've got some reading ahead of you, but there is no reason you couldn't do this.
In general, you cannot just kick everyone out. What you have to do is persuade each copy of Access to exit as gracefully (or not) as possible.
Search this forum for "Forcing Users to Exit" and phrases of that genre. Here's the overview of how you would do this.
1. You have to disable the F11 and Shift methods of bypassing normal Access startup because you need to create a Splash screen or startup screen that never dies. So search the forum for how to prevent users from bypassing startup forms.
2. The startup form or splash form CANNOT EXIT. But it can minimize itself, hide itself, and sit behind the scenes with a timer running on the form.
3. The form's .Timer property can be set for cycling once ever 60,000 msec = 1 minute. When the OnTimer event triggers, check for the pre-defined exit condition (see #5 below.) If the event code finds the condition, it executes a DoCmd.Quit - and keeps on doing so until the application exits. WARNING: This means that if you have "Cancel" returns on some events, you have a way of knowing that it is time to trigger and .UnDo and get the heck out of there. So there is some coordination.
4. The batch job needs to use a command-line feature of Access (see the Help files for Access Command Line options) that runs a macro. The macro should take some action that sets up your exit condition. For instance, it could run an Append query or do some sort of RunCode to muck around with a table's contents. The macro itself must ALSO do a QUIT as its last action, to release the database from the batch job, too. Otherwise it will hang open and be "the database that can never die...." (Sounds like an old Hollywood B movie of the 50's.)
SIDE NOTE: You CANNOT use a "global" variable in a general module's declaration area to do this BECAUSE variables, no matter HOW global or public they are, remain private to your workspace - because that is where they are instantiated. ONLY A RECORDSET can be as "global" as you need for this function.
5. The exit condition might be something simple, like a table with only zero or one records and only two fields - one of which is a non-autonumber PK and the other is a string. If you populate the table with a record that says, <#1, "Force these idiots out of MY database"> (or something gentler, if you wish), then the OnTimer event can do a DLookup of record #1. If it finds the keywords you choose, it forces the exit.
6. Presumably, you would do this to force database maintenance. When you do so, you must remember to reset the record, or take some other action that deletes or invalidates or otherwise prevents the record from forcing your exit, too.
7. To prevent others from futzing around with this table, make your chosen administrator account the table's owner and deny Write, Insert, Update, Append, or any other form of modification to all non-admin users. You would therefore need to implement Workgroup Security to get there from here.
Everything I've mentioned in every talking point can be Searched in this forum. You've got some reading ahead of you, but there is no reason you couldn't do this.
Fear Naught
Kevin
- Local time
- Today, 03:47
- Joined
- Mar 2, 2006
- Messages
- 229
What I do with one of my applications is to have a blank txt file (closedown.txt although any name will suffice). My application then checks at regular intervals if that file exists. If it does then fine no problem. If not it warns users that their application will close down in 30 seconds. I then have a routing to cleanly close their instance of the MDE file down and quit Access. I force this by changing the name of the file when I need to get users out.
This is particulay handy if there is a problem with the backend LDF file that can (and does) get locked preventing multiple users from logging in - including me!
This is particulay handy if there is a problem with the backend LDF file that can (and does) get locked preventing multiple users from logging in - including me!
- Local time
- Yesterday, 21:47
- Joined
- Feb 28, 2001
- Messages
- 30,567
My own preference was actually a schedule table that listed times and dates for DB down and DB up again, plus a brief text message of what was going to happen. Then, once per minute, I ran a query that looked for any records for which the current time was BETWEEN the event start time AND the event end time. If you tried to log in during the event, you got kicked out with a snippy message. If you were already in and the event time started, you got the "get out of Dodge" message within one minute.
But that's just me.
But that's just me.
hey All
I found this thing last night --
http://www.rogersaccesslibrary.com/download3.asp?SampleName=LogUsersOff.mdb
Already implented it; its very useful, and like the warning sign that changes colors
I found this thing last night --
http://www.rogersaccesslibrary.com/download3.asp?SampleName=LogUsersOff.mdb
Already implented it; its very useful, and like the warning sign that changes colors
mattkorguk
Registered User.
- Local time
- Today, 03:47
- Joined
- Jun 26, 2007
- Messages
- 301
We've been thinking of how to do that for ages!! Tested it just now and it works a treat!
Cheers bugsy!
Matt
Cheers bugsy!
Matt
mattkorguk
Registered User.
- Local time
- Today, 03:47
- Joined
- Jun 26, 2007
- Messages
- 301
I went for the linked table and the timer function from your switchboard form. I thought I could use it for other messages as well, to inform users of latest updates and the like. I'll see what feedback I receive...
Thanks again.
Thanks again.
mattkorguk
Registered User.
- Local time
- Today, 03:47
- Joined
- Jun 26, 2007
- Messages
- 301
Just as a little addition I have, after kicking them out, sent a text document to a known location (all users must it anyway to run Db) and then opened this document. So when they return to their desk it's waiting for them, stating why they were kicked out and when.
Code:
Dim db As DAO.Database
Dim snp As DAO.Recordset
Dim msg As String, intLogoff As Integer
Set db = CurrentDb
Set snp = db.OpenRecordset("Settings", dbOpenSnapshot)
intLogoff = snp![Logoff]
snp.Close
db.Close
If intLogoff = True Then
If Me.Tag = "MsgSent" Then
[B] DoCmd.TransferText acExportDelim, , "qryClosed", "C:\rst\" & "Closed.txt"
Dim retval
retval = Shell("C:\Windows\notepad.exe C:/rst/closed.txt", 1)[/B] Application.Quit (acQuitSaveAll)
Else
Me.Tag = "MsgSent"
DoCmd.OpenForm "frm_ExitNow"
End If
End If
