How to kick users off the mdb?

  • Thread starter Thread starter Ben
  • Start date Start date
B

Ben

Hi all,

I have a mdb file out on the network, I sometimes need to users exit out of
the database in order for me to update the code changes. But these users are
spread out all over the company either on location or at different sites.
Somestimes they do not respond to my email request to shut down.

I know there is a way to kick every one out, but could not remember how, can
you share some thoughts and suggestions?

Thanks in advance

Ben


--
 
While Daniel's given you a link to an example that will let you kick users
out, let's take a look for a moment at your reason why you wanted this
capability: "in order for me to update the code changes".

It sounds as though you haven't split your application into a front-end
(containing the queries, forms, reports, macros and modules), linked to a
back-end (containing the tables and relations). Only the back-end should be
on the server: each users should have his/her own copy of the front-end,
ideally on his/her hard drive.

Withat that set up, you make changes to your heart's content in your copy of
the front-end, then replace everyone's front-end once you're satisfied with
the changes. Tony Toews even provides a free utility that you can use to
ensure that each user has the correct version of the front-end. See
http://www.granite.ab.ca/access/autofe.htm
 
The answer is yes, but your post indicates you have one mdb with code and
data that multiple users are sharing over a network.

There are multipe problems with that kind of implementation. As you are
seeing a little bit of, it not only exposes you to corruption, performace
will be poor, and maintaining it becomes difficult.

The proper way to implement a multi user Access database application is to
split the database. You can use the database splitter wizard to do that.
Tools, Database Utilities, Database Splitter.

First, make a backup copy of your mdb. The run the database splitter. It
will create an additional mdb file that adds _be to the name of the file.
For example, if your file is name greatapp.mdb you will now have two files
greatapp.mdb will contain all your forms, reports, code modules, macros,
queries, and data access pages. This is the application

The other file file be greatapp_be.mdb
It will contain only tables and relationships.

That is how it should be.

Now put the _be on a shared folder on the network where all users have
read/write/delete permissions. They have to have these so they can create,
write to, and delete the ldb file for _be

Now you need to open greatapp.mdb (front end or fe) and link to the be
tables. It is important that you use UNC paths rather than Drive Mapping
because not all users will have the same drives mapped. For example, instead
of R:\SomeFolder\greatapp_be.mdb You would use
\\SeverName\SomeFoleder\greatapp.mdb.

Now, it is best if you then create an mde file for the fe, so you will have
greatapp.mde. This is the file you should deliver to your users. Each
should have their own copy on their computer, not on a network drive, and not
shared.

Now we have the issue of how to keep the users' copies of the mde up to
date. There are at least a couple of ways to do that. One is to put a copy
on the network that they can copy to their computer. You just send them all
an e-mail and tell them to copy the file to thier computers. This is simple,
but not very safe for a number of reasons. Another way is to put a shortcut
on their desktop that instead of running the app directly, runs a bat file
that copies the mde from the network to their desktop and runs it. That will
insure they always have the most current version. Better, but there is a
delay while the mde is being copied.

My preferred way is to use an automatic front end updater. Here is a link
to one you can modify to meet your needs:

http://www.granite.ab.ca/access/autofe.htm

You have to put some code into your application to make it work. You put a
one record table in the fe that has one field and it contains a value that
indicates what the current version is. You put a similar table in the be
that also tells what the current version is. Then in the startup code for
your app, you compare the fe version with the be version. If the fe version
is out of date, it launches the updater application and quits. The update
then renames the fe file as a backup and copies the current version from the
network location and launches it and quits.

This is a bit of work to set up, but will, I promise, make your life much
easier.
 
Back
Top