[AccessD] How to Manage Maintenance Mode - Auto shutdown

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



More information about the AccessD mailing list