Force to logoff

[Scott]

In order to conduct maintenance of the program, is there any utility to
force the current users to logoff?

Thanks,

Scott

 

[Albert D. Kallal]

Not really.

Remember, ms-access is just a document based system, and thus your question
is like:

how can we kick all people out of Excel.

You can put in a timer based system to track when the user has no activity
for a given period of time, and then shut-down ms-access (but, this is
occurring client side).

You can also setup some code that checks a value in a table, and if you
"set" this value, then again your code could check that value, and quit.

So, there is no "system" way, but you can roll your own approach.

Also, note that if you have a split database, then you can freely work on
the "next" great release/version of your application, and USER CAN CONTINUE
to work. So, consider using a split database. I talk about this concept
here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

 

[Arvin Meyer [MVP]]

Here's a demo of one way to do it:

http://www.datastrat.com/Download/KickEm.zip

 

[Tony Toews]

In order to conduct maintenance of the program, is there any utility to
force the current users to logoff?

HOW TO: Detect User Idle Time or Inactivity in Access 2000 (Q210297)
http://support.microsoft.com/?kbid=210297
ACC: How to Detect User Idle Time or Inactivity (Q128814)
http://support.microsoft.com/?kbid=128814

However we found that the code which runs on the timer event must be
disabled for the programmers. Otherwise weird things start happening
when you're editing code.

Also print preview would sometimes not allow the users to run a menu
item to export the report to Excel or others. So you had to right
click on the Previewed report to get some type of internal focus back
on the report so they could then export it. This was also helped by
extending the timer to five minutes.

The downside to extending the timer to five minutes was if a person
stays in the same form and at the same control for considerable parts
of the day, ie someone doing the same inquiries, the routine didn't
realize that they had actually done something. I'll be putting in
some logic sometime to reset this timer whenever they do something in
the program.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Scott]

Albert,

Thanks for your useful information. My database has been split into FE and
BE. However, when I put my new one to replace the old one, it fails if
someone is using it. Thus, I need a tool to kick all users out.

As far I remember, I have read a thread that there is a tool to do so but
cannot find it from Google.

Scott

 

[Scott]

Arvin,

Thanks for your demo db. I am unsure if I understand the operation
correctly. Do I import all the objects into my application first? Then, if
someone opens the database, I also open the database and check the getout
box and result in logging off all users. Your further advice if any
misunderstanding is appreciated.

Thanks,

Scott

 

[Scott]

Tony,

Thanks for your idea and sounds workable. I still need to wait for a while
if only one user is using the database. Definately, it is a way of clues.

Scott

 

[Rick Brandt]

Albert,

Thanks for your useful information. My database has been split into FE and
BE. However, when I put my new one to replace the old one, it fails if
someone is using it. Thus, I need a tool to kick all users out.

You should not have one front end that everyone uses. Each user should have
their own copy on their local disk. That way the centrally located front end
only serves as a file to be copied, not opened, so you can replace it whenever
you want without worrying whether it is in use or not.

The "kick em all out" utility's purpose is to free up the back end file when you
need to perform maintenance on that.

 

[Arvin Meyer [MVP]]

That's correct. You should have a copy of the program on each workstation.
Import the form and link the table to a table in the database. When you
check the getout box, they'll all be shut down and won't be able to log in
for very long.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[aaron.kempf]

Scott;

this is a MAJOR shortcoming in Microsoft Access MDB format.

Don't shoot the messenger; but lose the goddamn training wheels and use
SQL Server, jackass

using Access Data Projects; you don't have to deal with ANY OF THIS
CRAP

-Aaron

 

[aaron.kempf]

RE:
No.. YOU FUCKING RETARDS USE IT AS A DOCUMENT BASED SYSTEM.
ACCESS IS A REAL PROGRAM; SIMPLE EASY DATA BOUND FORMS AND REPORTS.

NOTHING ELSE IS HALF THIS EASY

but using MDB is a complete and utter joke; lose the fucking training
wheels.
I don't spend all my time looking up obsolete tools from the Access 97
toolkit

'jet utilities'

I dont put my marbles in the MDB format-- because I DONT TRUST IT
ENOUGH

lose the training wheels you fucking idiots; MDB is for _LOSERS_

ADP is 10 times easier (development), bigger, better and FASTER.

 

[Scott]

Arvin,

Many thanks for your further advice. Did you mean all objects imported to
the FE database only? If so, I am confused that should I put the linked
table, KickEmOff, in the BE database and then linked to FE databases on each
workstation?

Scott

 

[Arvin Meyer [MVP]]

If you don't put it on the server (back-end), there is no way of
communicating with each workstation. So:

1. Put the table on the server.
2. Link that table to the front-end on each workstation
3. Put the form on the front-end and hide it.
4. Use the form as the startup form, or open it with the startup form.
5. In case you have some users who think they know everything, also open it
from other major forms.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[aaron.kempf]

that's ridiculous

put everything in an Access Data Project and you just don't have to
worry about all this crap

it's easier, faster, better, stronger, cheaper, more reliable and more
secure

MDB is pointless

-Aaron

 

[Tony Toews]

Thanks for your idea and sounds workable. I still need to wait for a while
if only one user is using the database. Definately, it is a way of clues.

But from your other postings you are sharing the FE on the server.
This isn't a good idea as it can lead to corruptions. And, as you've
found out, it is difficult to put in a new copy.

However you really want to put the FE on each machine or place in a
user specific directory on the server. This will help avoid some
weird error messages when users are changing the same forms record
source, filters and such as well as corruptions. It is also much
easier to implement a new version of the database with changed
queries, forms, reports and VBA code.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[aaron.kempf]

listen to these guys

what a load of crap

use Access Data Projects; it's 10 times simpler; development is FASTER

and you have REAL TOOLS for ETL and for Analysis and for
Administration.

SQL Agent? why reinvent the wheel?

mdb is _TOTALLY_ obsolete guys

-Aaron

 

[Scott]

Tony,

I am at loss why you interpret that my FE is located on the server. Only
the BE is located on the server and FE is located on each workstation.
Anything referred to server means on BE, not FE.

Scott

 

[aaron.kempf]

Albert;

that is the most ridiculous concept I have ever heard of in my life.

WIth Access Data Projects this is HELLA EASY (kill 50)
with ADP it's unnecessary in most situations because it doesn't lock
the whole database whenever somebody is using a single record lol

It's just comical; Access is not 'just a document based system'

that's the most ridiculous analogy i've ever heard of in my life.

MDB is a crappy ass format.. get off your big fat lazy ass and
MoveOn.org
MDB is a crappy ass format.. get off your big fat lazy ass and
MoveOn.org
MDB is a crappy ass format.. get off your big fat lazy ass and
MoveOn.org

 

[Tony Toews]

Tony,

I am at loss why you interpret that my FE is located on the server. Only
the BE is located on the server and FE is located on each workstation.
Anything referred to server means on BE, not FE.

I got that from the following statement: "However, when I put my new
one to replace the old one, it fails if someone is using it. Thus, I
need a tool to kick all users out."

Now I did make the assumption that this was on the server so clearly
I'm wrong there.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[aaron.kempf]

you know what they say about assumptions?

do you know what they say about MDB?

ROFL

-Aaron