John W. Colby
jwcolby at colbyconsulting.com
Wed Aug 17 18:47:33 CDT 2005
I have workstations running an application (call center for AIG Insurance company - Disability claims division) that hit the BE on the server. I have an entirely different application (email reporting FE, reports new claims and authorizations to pay claims back to AIG Insurance company) running only on the server that hits the be on the server. It is NOT being fired off by the Windows scheduler, it runs 24/7 and has it's own logic to decide when reports need to go. In fact that same application also RECEIVES emails from AIG Insurance company which contain Excel attachments containing payment information. These emails cause an outlook object to fire events that are sunk in one of my classes, which then process the emails. These payment files get stripped off the email, placed into directories on the server, linked to the Email Reporting FE, and subsequently appended into tables in the same BE that the call center software is hitting. This payment info is then available to the call center personnel when the person filing a claim calls and asks "where's my check". Everything hitting the BE on the server needs to shut down when I ask it to. I do NOT want MY application running on the server to shut down the workstations, I want your EXE (SOME APPLICATION) (running on the server) that shuts down the workstation Fes to also shut down the Server Email Reporting FE. Three things running. Call Center Fes on workstations (often left on overnight). Email Reporting application. Payment Import application. ALL this stuff needs to shut down when I need access to the BE. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Wednesday, August 17, 2005 7:14 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Force Remote Shutdown Instantly! No timers (sort of)WAS:RE: [Ac cessD] How to Manage Maintenance Mode - Auto shutdown Okay, and what is it that you want to shutdown? I'm a little confused. If the backend is an .mdb, there is nothing to shut off, it's a file share, not a service. The workstations running off of that backend (with their frontends) could be shutdown with the sample I posted. The application that sends emails, which is running on the server (and I'll assume it's an Access application being fired off by the scheduler service), that sounds like it's a start, run, stop process. If you need to interupt it, (not sure how long it takes to run), but you could use the TCP protocol approach, if it needs to be interrupted from another application (but you haven't listed another application....so far it's only the report/email application...the .mdb itself is not a 'running' application. Now, if you want to have the application on the server (which runs and emails the reports) to have the ability of shutting down the client front ends on the network workstations, then just port the VB .exe I posted into it, so that IT sends out the message for the clients to shut down. That portion CAN run from a machine running anything you want. The clash is in the UDP protocol, since it is connectionless, it has to have both the local and remote ports set, so you can't have two applications (the .exe and an .mdb) running the same ports on the same machine, they will clash! Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Wednesday, August 17, 2005 5:56 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Force Remote Shutdown Instantly! No timers (sort of)WAS:RE: [Ac cessD] How to Manage Maintenance Mode - Auto shutdown >Why not just turn it off? Because it is an unattended server. The server is a file server serving the BE to the main application running on workstations. The server also runs an application that sends documents to my client's client via email. At specific times of day the application runs a process to send out the email with a report attached. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Wednesday, August 17, 2005 5:52 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Force Remote Shutdown Instantly! No timers (sort of)WAS:RE: [Ac cessD] How to Manage Maintenance Mode - Auto shutdown Huh? You have an application on a machine, let's call it 'ServerA'. That application is an .mdb, running in the Access environment, right? And you need a way to to that application off.....from ServerA? Why not just turn it off? Now, if you are running two processes, both on ServerA, and you want one process to 'shutdown' the other, okay, that's easy, switch from UDP to TCP. You can easily connect to an app on the same machine with TCP. (The first sample I posted today does that, if it determines the client is on the same machine as the server). Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Wednesday, August 17, 2005 4:36 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Force Remote Shutdown Instantly! No timers (sort of)WAS:RE: [Ac cessD] How to Manage Maintenance Mode - Auto shutdown >You don't NEED to shut down a LOCAL machine's application REMOTELY! Eh? LOL) Just goes to show, you never know. I have a server running an application. I would be running this udp server exe on that server, and it would need to shutdown that app. But who's quibbling. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Wednesday, August 17, 2005 4:18 PM To: accessd at databaseadvisors.com Subject: [AccessD] Force Remote Shutdown Instantly! No timers (sort of)WAS:RE: [Ac cessD] How to Manage Maintenance Mode - Auto shutdown Okay, JC asked about using UDP in reverse. Since I don't know how experienced ya'all are with winsocks and TCP/IP communications, I decided to whip something up. http://www.marlow.com/RemoteShutdown.zip Here's how this works. Inside that zip you'll find an Access 2000 database with one form and an AutoExec macro (sorry, not writing complete startup code just for a sample). The AutoExec opens frmUDPServer 'hidden'. That form just sits there, and does absolutely nothing, until UDP comms come into port 9999. When the comms come in, there are three options, it will either directly shutdown (docmd.Quit), it will display itself and give the user 10 seconds to cancel the shutdown (that is why this uses a timer, the timer event only starts running during the 'prompted shutdown'), or it will display a message (msgbox). Also, inside the zip, you'll fine testclient.exe (along with the VB source code for that .exe). When you run that, you'll find that a textbox, listbox, and three command buttons. The three buttons do what they say. Click Shutdown Clients, and ALL Access sessions on your network, that have frmUDPServer running in the background will close. Click 'Ask To Shutdown', and ALL Access sessions with frmUDPServer running in the background will now display frmUDPServer, and give the user 10 seconds to cancel the shutdown. Click 'Send Message To Clients', and a msgbox will appear on all of the same machines with the text of what is in the 'Data To Send' labeled textbox. A few special items to note. Pressing Any of the three buttons, while running an Access .mdb with frmUDPServer on the same machine will result in a 'Cannot use this if a server is running locally!' message, and nothing will happen. It's a limitation of UDP comms, but that DOES NOT limit this application. (You don't NEED to shut down a LOCAL machine's application REMOTELY! Eh? LOL). So if you want to test this, you will need two machines, one to run the .mdb, and one to run the .exe. Next note, this uses the winsock .ocx. As I mentioned in a reply to JC earlier, this could all be done with API's if so desired, but honestly, I just don't have time to write this all out with API calls. Next note, almost forgot the listbox. When frmUDPServer gets a message from the network, it sends back it's computer name. So the listbox will populate with all of the machines running frmUDPServer that have received a message from the .exe through the network. A note about subnets/lans/NICs. If frmUDPServer is running on a machine that has multiple NICs, it is going to receive a message for each NIC it has. This isn't a concern for the shutdown, and the prompted shutdown (though the prompted shutdown will delay a little longer, because the first hit will start it, and the second, third, fourth, etc hits will reset the time on it....so the countdown won't really countdown until all of the hits come in. (Unless your network is literally crawling, this will all take less then a second....). Sending messages, however, will popup on their machine for each NIC they have (and on the listbox, you'll see that computername show up for each message 'received'. Last note, BE CAREFUL. This is a SAMPLE project, and I personally wouldn't use it in a live system as is. (That is why I sent the VB source). frmUDPServer has absolutely no safeguards in place. It receives a particular string, it stops Access. I personally would recommend a little tighter 'confirmation'. For sample purposes, I'm simply sending out a simple string 'ShutdownNow' (I think). I would make that a little more complex, so that you don't provide an easy method for a hacker to go around shutting down your applications. Enjoy! Drew -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com