Force Exit on Timer (3 Viewers)

[phillip]

Trying to find a good solution that will force my frontend to quit (exit without warning) if the frontend has been idle for 60 minutes. The tables are stored in a separate backend database and linked to the frontend. Any suggestions or sample databases are much appreciated.

 

[theDBguy]

Hi. Welcome to AWF!

There used to be a demo for that at UA. Sadly, it's inaccessible now. I don't think the wayback machine can help you with that either. Have you tried searching through the sample databases forum here?

 

[Gasman]

Trying to find a good solution that will force my frontend to quit (exit without warning) if the frontend has been idle for 60 minutes. The tables are stored in a separate backend database and linked to the frontend. Any suggestions or sample databases are much appreciated.

Have a look at

https://www.youtube.com/results?search_query=force+access+frontend+to+quit

 

[arnelgp]

try this video:

 

[Gasman]

Also look here

 

[Mark_]

From a UI perspective, please make sure you give the user some kind of warning, say 5 minutes before.

 

[isladogs]

From a UI perspective, please make sure you give the user some kind of warning, say 5 minutes before.

Agreed though I allow a shorter interval - maybe 30 seconds.
Providing the user takes any action within the specified time interval, the countdown timer automatically resets to zero

 

[phillip]

From a UI perspective, please make sure you give the user some kind of warning, say 5 minutes before.

Thanks for the input. The issue is that some users leave the db open after hours which restricts me from being able to update the tables if needed at night when I do Maintenace and updates to the backend.

 

[isladogs]

That’s the reason why many of us have included code to force out users after a period of inactivity. I usually allow 20 minutes with a warning just before that expires

 

[phillip]

Great idea - thanks again for the input

 

[theDBguy]

Thanks for the input. The issue is that some users leave the db open after hours which restricts me from being able to update the tables if needed at night when I do Maintenace and updates to the backend.

For that scenario, it gets even easier. I didn't comment on anything specific earlier, because I couldn't remember how to detect "idle" time. But in your situation, you simply execute a trigger that the FE is listening for, so you can warn any active users that maintenance is about to begin. They either close their session or you force them out (for those who either ignored the warning or have left their desk for the day/night).

 

[The_Doc_Man]

I had a table of scheduled outages. Each login included a computation of the amount of time until the next scheduled down-time. The table always had TWO entries - down time and return-to-service time - and all logins except mine were disallowed during the gap between those two times. When the user logs in within 24 yours of the next down time, they got a notification in a thing that looked like (but wasn't) a Message Box (OK Only type) and a timer would start based on a little math to get to 1 hour before down time, but when THAT expired, they got a 30-minute warning, then a 15-minute warning, then 10, 5, and 1. The funky box was to prevent some bright kid from thinking they could simply ignore the OK button. The users know that when the countdown hit 0, the DB would start shutting itself down and nobody could stop it except me. At first they hated me but eventually they caught on.

 

[isladogs]

This is my deliberately over-the-top form which is displayed during the countdown to forcibly closing the app for essential maintenance.

It was designed like that so it wouldn't be ignored.
Users can temporarily hide the form to complete their work but it returns every 30 seconds until shutdown

 

[xavier.batlle]

That’s the reason why many of us have included code to force out users after a period of inactivity. I usually allow 20 minutes with a warning just before that expires

It's also a good idea to prevent users from opening the backend database when there are some maintenance tasks to do. In my case when they open the Application, if there is a file called "EnterDenied.txt" in the same directory where is the backend stored they are unable to open the backend database. When the maintenance tasks are finished I delete that txt file.

 

[arnelgp]

It's also a good idea to prevent users from opening the backend database when there are some maintenance tasks to do.

i think that is already covered by the "hidden startup" form of isladog.
on the db startup, it first check the "linked" table if the Yes/No field is checked for maintenance.
if it is checked, the database will not continue to open.
if not checked, it has a timer event that continuously checked the status of the Yes/No field.
if it found that it is checked while the db is in use, it will make itself visible with it's message.
the user will have the option to close it (actually it will get hidden again) and the
count down still continues until it reaches the Max count and will force close (and save)
all open form, all open reports, etc.

 

[xavier.batlle]

i think that is already covered by the "hidden startup" form of isladog.
on the db startup, it first check the "linked" table if the Yes/No field is checked for maintenance.

But if I'm not mistaken with that approach you first have to open the backend databasase where "the linked table if the Yes/No field" is, and it might be corrupted or blocked, etc.

 

[isladogs]

@arnelgp has very accurately described how my 'kickout' system works.

Once the system has been locked, new users cannot login to the FE.
A different warning dialog appears at startup and the app closes automatically.

In my apps, the boolean Kickout field is in a linked SQL Server table zAppInfo so users have no direct access to it or any other data tables.

The text file approach also works but isn't necessary with my approach.

 

[Mark_]

But if I'm not mistaken with that approach you first have to open the backend databasase where "the linked table if the Yes/No field" is, and it might be corrupted or blocked, etc.

The table being access does not need to be in the same "back end" as is being maintained. It can easily be in a totally separate back end in a different location from your main database. That is the nice part about linked tables, they don't all have to be in the same file, same directory, or same server.