DWUTKA at marlow.com
DWUTKA at marlow.com
Wed Aug 17 13:07:40 CDT 2005
download the demo I whipped up this morning. http://www.marlow.com/UDPTest.zip it's a VB project. Actually 2. Ones a client, ones a server. In the other thread, I was discussing that you could set up a VB NT Service as the 'server', and the Front End's as the 'clients'. The Front Ends can then query the server (with no hard link, the code I have in the demo 'scans' the entire subnet/LAN in a split second, and receives the response if there is an active 'server'. I suggested using this as a table linker, where the 'server' has a list of database paths, and with the correct 'prompt' from the client, it would return the correct path for that network. If you use this process in reverse, making the Front End's the 'server' (so you would have multiple servers, with one client), and make a 'control client', you could send out (from the client) a message that the servers would receive, and deal with as you wish. ie, 'ShutDownNow' or 'AskToShutDown', or 'AreYouActive'. The message would simply be sent out, and the online clients could then react to the message. No timer. Now, as an FYI, the VB projects I have in there use the Winsock OCX. For me, that is no issue at all, since I have a VB program installed on all client machines here, which uses it, so it's registered on every machine we setup here. However, I know in the pure Access world, OCX's are sometimes frowned upon due to their requirement to be set up on client machines they don't exist on. Winsock code can be done strictly through API's though, which eliminates the need for the Winsock OCX. However, and this is the catch with Access, the API's for window's sockets use the Window Messaging queue for receiving data from TCP/IP comms. To do that, you have to use callback functions. (when you subclass a form/window, to put it in the system tray, you use the windows messaging callback to determine what is happening to the icon in the system tray). Callbacks in Access 2000 and up (not sure if it is fixed in later versions of Access, I know 97 is fine, and 2000 is not, so I'm not sure if 2002 or 2003 work correctly or not....) make development a little quirky. In a finished state, there is nothing wrong. However, if a callback procedure is 'hooked', and you go into debug mode with the VBA code, you'll lock up Access 2000 (again, don't know if this is fixed with later versions). Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Wednesday, August 17, 2005 12:44 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] How to Manage Maintenance Mode - Auto shutdown Woa, talk to me. A dll or something which sources events, which can be sunk by a class in the FE? I am in need of something non-timer related. Timers just suck in Access. 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 1:32 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] How to Manage Maintenance Mode - Auto shutdown Actually, with the UDP comm stuff I am talking about in the 'I Need Some Ideas' thread, a listening with UDP to a specific port would provide a way to 'shutdown' remote FE's relatively instantenously, from a central point. Drew -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] Sent: Wednesday, August 17, 2005 12:13 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] How to Manage Maintenance Mode - Auto shutdown The problem with that method is that if anyone leaves their FE open overnight (always on) the task can never run. The only alternative that I know of is to have a form always open in every FE, running a timer. The timer tick can do one of several things, including just checking a table for a shutdown flag and informing the user that a shutdown will occur etc. In the end though the form and its timer has to do the shutdown. 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 Charlotte Foust Sent: Wednesday, August 17, 2005 1:00 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] How to Manage Maintenance Mode - Auto shutdown We generally don't have polite automatic shutdowns, since our software could run for hours waiting for someone to finish a task and enter the data associated with it. If we have something along those lines (or we need to compact/repair the front end) we set normally up the code to run when it can get an exclusive lock on the database. That just means that when it thinks it should do this, as when the user is closing down, it checks to see whether it can. The same checks will happen on any machine, so the last one to close down wins the prize of running the maintenance routines. What specific kinds of maintenance were you going to run? Charlotte Foust -----Original Message----- From: Mark Breen [mailto:marklbreen at gmail.com] Sent: Wednesday, August 17, 2005 9:37 AM To: accessd at databaseadvisors.com Subject: [AccessD] How to Manage Maintenance Mode - Auto shutdown Hello Group, I have an app uses MS SQL 2000 Server as it's backend database. I want to run some maintenance routines on the db and they require that I switch the db into single user mode. This is easily done and once I have it in Single User Mode, it is easy to kick off the maintenance routines. My question is what ways you may have handled a polite automatic shutdown of the application in your worlds. Technically, I do not have to shut down my app, I could just break the connection to SQL server, but I think that I may as well shut down the entire app. I could use timers, and I could insert 'activity' updates and only shut down the FE app when the app is not being used. So for example, I could update a database field and when the field has not been used for more than 30 minutes I can assume that it is in-active. This would allow me to auto shut down the app, but I would like to leave some message behind me to let the user know where their app went rather than just killing it! I could also break the connection to the db, then display a message box saying the db has been shutdown and allow the user to click OK to continue. I am not seeking detailed technical help here, more philosophically how you guys handle this type of situation. Any thoughts or comments are appreciated, I hope you and your family are all well, Mark Breen -- 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