468,790 Members | 1,819 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,790 developers. It's quick & easy.

Can you force Access to quit when PC goes into Standby mode?

2,321 Expert Mod 2GB
In the office users often leave my application running when they go for lunch. While they are away the PC will go into standby or suspension, and the network access will be lost, causing a error message when the users return to their machines, not to mention that the backend is usually blocked from edits even though noone is actually using the database.

Is there any way to react to windoze going into standby and force - quit access?
Aug 30 '12 #1
17 6229
3,652 Expert Mod 2GB

They key may be to keep it from going into standby mode....

See this thread, which was actually spawned by your question:

Reset System Idle Time

This may be a workaround....
Aug 30 '12 #2
12,515 Expert Mod 8TB
You can use WMI for this. You'll want to put it in a .VBS file and call it when the database is opened.

Expand|Select|Wrap|Line Numbers
  1. Option Explicit
  3. Dim objWMIService, colItems, objLatestEvent
  5. Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
  6. Set colItems = objWMIService.ExecNotificationQuery("Select * from Win32_PowerManagementEvent")
  8. While True
  9.     Set objLatestEvent = colItems.NextEvent
  10.     WScript.Echo "A power management event happened" & vbcrlf & "Event type: " & objLatestEvent.EventType
  11.     ' EventType
  12.     ' 4  - Entering suspend
  13.     ' 7  - Resuming from suspend
  14.     ' 18 - Resume Automatic happened
  15. WEnd
Aug 30 '12 #3
12,515 Expert Mod 8TB
I was wondering if the code worked for you?
Aug 31 '12 #4
2,321 Expert Mod 2GB
Sorry for not getting back to you. To be honest I dont immediately understand your solution and need to spend a bit of time on google first.
Aug 31 '12 #5
12,515 Expert Mod 8TB
Basically, windows has this object called the WMI, or Windows Management Instrumentation. This object allows you to access all kinds of information about windows, hardware, software, and events happening on the computer.

Lines 1 and 3 are self explanatory.

Line 5 retrieves the WMI object for the current computer. (It can be used to get info about and manage remote computers as well.)

Line 6 runs a query for power management events.

Lines 8 and 15 establish an infinite loop to check for events.

Line 9 retrieves the next power management event.

Line 10 is a message box to describe what event just occurred.

And so what you want to do is replace line 10 with something like, if the event type is 4, then the computer is about to enter suspend mode, so quit out of Access.
Aug 31 '12 #6
2,321 Expert Mod 2GB
Thank you. I still need to check up on how to run a vbscript from Access and how to make the vbscript quit access, and preferably the right session in case the user has another database open.
Aug 31 '12 #7
12,515 Expert Mod 8TB
I suspect the answer may be that the users run a vbscript that creates an access application and opens the database and then sits in the background and monitors.
Aug 31 '12 #8
2,321 Expert Mod 2GB
Would there be any benefit or trouble from running the access application from a script?
Aug 31 '12 #9
12,515 Expert Mod 8TB
The main benefit would be that you get to run code outside the Access process. Which allows you to do stuff without tying up Access. If you plan on doing other stuff aside from monitoring when the computer goes into sleep mode however, you will need to use the asynchronous version of the WMI query.

For example, you can use it to update the front end, monitor computer resources, idle time, lock state, etc. While all of this, with the exception of updating the front end, can be done within the access application itself, it ties up the application to do the monitoring tasks.

As far as drawbacks, I haven't seen any nor do I forsee any. There might be some slight hiccups, such as if the script fails to initialize, then the database won't open. You can get around that by creating and opening the database first. Because even if the script crashes during it's run, it won't close the database unceremoniously.

A fully functioning script could look something like this
Expand|Select|Wrap|Line Numbers
  1. Option Explicit
  3. Dim objAccess, objWMIService, colItems
  5. Set objAccess = CreateObject("Access.Application")
  6. objAccess.Visible = True
  7. objAccess.OpenCurrentDatabase "C:\Database1.accdb"
  9. Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
  10. Set colItems = objWMIService.ExecNotificationQuery("Select * from Win32_PowerManagementEvent")
  12. Do While True
  13.     If colItems.NextEvent.EventType = 4 Then
  14.         objAccess.Quit
  15.         Set objAccess = Nothing
  16.         Set colItems = Nothing
  17.         Set objWMIService = Nothing
  18.         Exit Do
  19.     End If
  20. Loop
Aug 31 '12 #10
3,652 Expert Mod 2GB
Would it also be possible to run this from a blank, hidden form that starts any time the database is opened, and simply runs this code in the background?

I use that trick to force users out remotely when I want to run updates.

And.... methinks I could learn much from this Jedi named Rabbit.....
Aug 31 '12 #11
12,515 Expert Mod 8TB
@twinny, unfortunately no. Here's why.

The NextEvent method will not return until an event has occurred. So Access will freeze up until a power management event occurs. E.G. the computer goes to sleep.

Having said that, there is an asynchronous version of the WMI query. Unfortunately, I have not found a way to get that working within Access itself. You get some error about it not being able to find the remote host. And I haven't found a way around that error yet.
Aug 31 '12 #12
12,515 Expert Mod 8TB
Having said that I had yet to find a way to get the asynchronous query to work, I have gotten the asynchronous query to work.

I used a class module for this. Conceivably you can do it all in a form if you wanted. You will have to add a reference to the Microsoft WMI Scripting Vx.xx Library. Whatever your version turns out to be.
Expand|Select|Wrap|Line Numbers
  1. Option Explicit
  2. Dim WithEvents sink As SWbemSink
  4. Private Sub sink_OnObjectReady(ByVal objWbemObject As SWbemObject, ByVal objWbemAsyncContext As SWbemNamedValueSet)
  5.     If objWbemObject.EventType = 4 Then
  6.         Application.Quit
  7.     End If
  8.     Set objWbemObject = Nothing
  9. End Sub
  11. Private Sub Class_Initialize()
  12.     Dim services As SWbemServices
  13.     Set sink = New SWbemSink
  14.     Set services = GetObject("winmgmts:\\.\root\cimv2")
  15.     services.ExecNotificationQueryAsync sink, "Select * from Win32_PowerManagementEvent"
  16. End Sub
And in your form, something like this.
Expand|Select|Wrap|Line Numbers
  1. Option Compare Database
  2. Option Explicit
  3. Public sinker As Class1
  5. Private Sub Form_Load()
  6.     Set sinker = New Class1
  7. End Sub
Aug 31 '12 #13
2,321 Expert Mod 2GB
Thank you very much for your help so far. I will try to implement this during the next week.
Sep 1 '12 #14
12,515 Expert Mod 8TB
Just wanted to follow up, were you able to get this to work?
Sep 12 '12 #15
2,321 Expert Mod 2GB
Embarrassed to say that I have not found the time to test this yet. I did notice you putting together an article as well, which looks very nice.
Sep 12 '12 #16
Josh Reagan
1 Bit
Thank you Rabbit! The class module and form worked for me. Is there a way to use late binding instead of Microsoft WMI Scripting library reference?
Jun 11 '21 #17
12,515 Expert Mod 8TB
It's been forever since I've looked at this. I don't know if you can late bind it due to the events, but I've never tried.
Jun 14 '21 #18

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

reply views Thread by Shelley | last post: by
3 posts views Thread by Frank Rizzo | last post: by
reply views Thread by =?Utf-8?B?Z3Jsb25n?= | last post: by
reply views Thread by zhoujie | last post: by
2 posts views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.