[AccessD] forced logout

John W. Colby jwcolby at colbyconsulting.com
Wed Feb 11 20:02:25 CST 2004


Mark,

It is not necessary to delete the other tables.  As long as no bound form is
open, and no recordsets in code are open, then the FE will not be "IN" the
BE.  And yes, this "bound to the shutdown BE concept would certainly work.

The shutdown widget I'm designing has a shutdown table with all information
in it.  The purpose was mostly to have a "template" table with a few example
records in it, as well as a test table during design.  There's no reason it
couldn't just use this table.  My widget is an MDA of course with the code
and table all in one.  If you wanted to control shutdowns in more than one
FE you would need to move the table out into a "BE" or use a COPY of this
MDA for each FE being controlled.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Mark A Matte
Sent: Wednesday, February 11, 2004 9:47 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] forced logout


Hello All,

In following this thread...I was awaiting the answer...because I've had the
same question...How to inform them its ok to go back in...If they have the
FE open...doesn't it 'open' then BE?  I don't know if my idea is
feasible...but it was inspired by John's statement:

"If the FE links to 3 different BEs on different machines, where is "the BE
directory"?  "

Create a separate BE with 1 table (all of the SHUTDOWN criteria)...link to
this table...When your criteria is met...delete/disable your linked tables
in the FE...minus the SHUTDOWN table...Your FE continues to check the
SHUTDOWN table...when it is time...recreate/enable your links in the FE.
I'm pretty sure this can all be done in VBA.

Just a shot in the dark...but almost makes sense to me...please let me know
if it does to anyone else.

Thanks,

Mark A. Matte




>From: "John W. Colby" <jwcolby at colbyconsulting.com>
>Reply-To: Access Developers discussion and problem
>solving<accessd at databaseadvisors.com>
>To: "Access Developers discussion and problem
>solving"<accessd at databaseadvisors.com>
>Subject: RE: [AccessD] forced logout
>Date: Tue, 10 Feb 2004 21:33:19 -0500
>
>That is surely an idea.  OTOH I want to be able to edit a record in a table
>dynamically to allow the FE to see that it is time to log out.  One problem
>with "the back end directory" is that it may not even exist, or it may be
>several different directories.  If you are using SQL Server, where is "the
>back end directory"?  If the FE links to 3 different BEs on different
>machines, where is "the BE directory"?  Of course you can then define a
>directory field in a table that the logout code looks in to see this file.
>
>And of course, what about web pages hitting the be?  How do you tell them
>to
>stay out for a time period?  With a table they could essentially use the
>same logic the FE uses.  this brings up the issue of time zones of course.
>The record needs to include the time zone that the database server resides
>in since
>
>And sure, different computers could have different times.  If that is an
>issue there are programs that can be run on each workstation that sync the
>workstations to the server's clock.
>
>John W. Colby
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Stuart Sanders
>Sent: Tuesday, February 10, 2004 8:48 PM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] forced logout
>
>
>I was thinking over this just recently.  The problem I have with a pure
>time
>based system is that different computers can have different times.
>Normally
>this should only be a matter of minutes, but not always.
>
>I saw someone mentioned something like this before and was thinking that
>one
>way
>would be to create a zero length file in the backend directory.  You could
>use
>different filenames for different purposes:
>BESD10.txt - Shutdown in 10 minutes.
>BESD5.txt - shutdown in 5 minutes
>BESD.txt - immediate shutdown.
>BENL.txt - no login allowed
>
>(.txt isn't needed ... Just an illustration)
>
>The reason for this is that most backup programs allow the running of
>scripts
>before and after backup occurs.  And by simply copying a file into the BE
>directory and deleting it when done you give the server the ability to
>centrally
>control automated jobs that require users to logout without having to guess
>how
>long such jobs will take.
>
>Just an idea...
>
>Stuart
>
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
> > John W. Colby
> > Sent: Wednesday, 11 February, 2004 9:10 AM
> > To: Access Developers discussion and problem solving
> > Subject: RE: [AccessD] forced logout
> >
> >
> > The reason can be anything.  I need to ensure all users are out of the
> > database every night so that compact can occur.  Also I need
> > to be able to
> > get in and do BE maintenance, modify tables if necessary etc.
> >  The users are
> > leaving the FE (bound forms) open.
> >
> > John W. Colby
> > www.ColbyConsulting.com
> >
> > -----Original Message-----
> > From: accessd-bounces at databaseadvisors.com
> > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of
> > bruce_bruen at mlc.com.au
> > Sent: Tuesday, February 10, 2004 5:11 PM
> > To: Access Developers discussion and problem solving
> > Subject: Re: [AccessD] forced logout
> >
> >
> >
> >
> >
> >
> > That would depend on the reason for forcing the logout surely?
> >
> > If the reason is due to a db corruption discovery or to a maintenance
> > shutdown then the database should be reopened by an
> > administrator manually.
> > If OTOH the logout is forced by some business rule then that rule is
> > incomplete unless it defines the reactivation.
> >
> > B
> >
> >
> >
> >                       "John W. Colby"
> >                       <jwcolby at colbyconsulting.        To:
> >    "AccessD"
> > <AccessD at databaseadvisors.com>
> >                       com>                             cc:
> >                       Sent by:
> > Subject:  [AccessD]
> > forced logout
> >                       accessd-bounces at databasea
> >                       dvisors.com
> >
> >
> >                       11/02/2004 09:01
> >                       Please respond to Access
> >                       Developers discussion and
> >                       problem solving
> >
> >
> >
> >
> >
> >
> > I am almost finished with a class and a table to allow me to
> > force a logout
> > of my users from  the db.  In fact it is all working now, the only
> > remaining
> > question is "when do I let them back in".
> >
> > Is anyone else doing this?  What is your answer?  My tendency is "keep
> > logged out between ThisTime and ThatTime", i.e. add a second
> > time field to
> > the table that is the time to allow back in.
> >
> > Anyone?
> >
> > My current system uses:
> >
> > usysTblShutdown:
> >
> > SD_ID                    - autonumber PK
> > SD_Name            - Shutdown name
> > SD_Time            - Time to shutdown
> > SD_Enabled         - THIS shutdown is enabled
> > SD_Warnings        - The number of warnings to display before
> > forcing a
> > shutdown
> > SD_WarningTime           - the number of seconds between warnings
> >
> > I have a form that my framework opens that initializes the
> > framework, and
> > shuts it back down if the form tries to close.  Thus enabling a clean
> > shutdown regardless of anything other than perhaps a power failure.
> >
> > I then use the timer for this form to call a method in my class which
> > checks
> > whether to do the shutdown.  The class raises an event with
> > every warning
> > to
> > the user in case your app needs warning that a shutdown is
> > imminent.  The
> > class also raises an event when it is finally time to actually do the
> > shutdown.
> >
> > I will publish the whole in a demo database as soon as I
> > handle the issue
> > of
> > when to allow them back in.  All opinions welcomed then summarily
> > dismissed.
> >
> > ;-)
> >
> > John W. Colby
> > www.ColbyConsulting.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
>
>
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com

_________________________________________________________________
Get some great ideas here for your sweetheart on Valentine's Day - and
beyond. http://special.msn.com/network/celebrateromance.armx

_______________________________________________
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