Switching to a multi-user scenario

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The database I am managing (I didn't create it) is currently running as a single-user scenario. The whole program, data & all tables are kept on the server, but it's not split. We have 12 computers (users) that access this database, and usually they are all in it at once. What we want to do is break the users into groups and put passwords on the "group" and give them access to different information in the database.

I know that I need to split the database in order to do this, but what I'm looking for is a general idea on how much work it is to do what we're trying to do, as I am writing a report to indicate if this is a plausible option in our organization and how long it might take to do it (I'm not doing it for free!).
Does anyone have any thoughts on this? I'm not sure if what I want to do is possible, or easy, or if it would be easier to start over and re-build the database completely.

Thanks in advance, and the sooner I can get a response, the better, as I am trying to write this report today
Melissa
 
You sound like you are on the right track here.

Splitting the database is not hard, and 99% of the time, no code need to be
changed.

You probably should consider implementing security..and some "groups" to
control who can do what. (say, some users can't delete, or run certain
reports for example).

Learning and setting up security is not too hard, but you MUST sit down, and
learn how it works (be prepared to do some reading..as it is quite confusing
at first).

Also, you should note that splitting and placing a front end on each pc
solves a number of problems.

First, by placing the FE (front end) on each pc, reliability of the system
will go up huge fold. In fact, so much so, that I could not really recommend
running ms-access any other way. So, your goal, and question on this is
good.

Further, each front end should be a mde as this will prevent users from
being able to modify the application (and, again, it also tends to be more
reliable).

Also, when the system is split, then you are free to work on updates, or the
next great version. You are free to test, code, make reports etc and NOT
impact the current system that is running. After you test, and are happy
with your "new" update, then this new front end is then distributed to all
the pc's. In fact, Tony has written a auto FE updater that will do this for
you (saves you running around to update).

You can also forgo implementing security, and actually distribute a
different version to people who are only supposed to do certain things.
However, by having different FE for different people..then YOU kind of have
to maintain more then one FE, and thus I don't really recommend this
approach.
Does anyone have any thoughts on this? I'm not sure if what I want to do
Click to expand...
is possible, or easy, or if it would be easier to start over and re-build
the database completely.

Oh, my..no, I would not start over. If hte applction runs well, and does
what it is supposed to do..then adding, and impleting secity and new
featrures can be built on what you have now..

for info on splitting you can check out:

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

For security...you will need a good pot of coffie...here is one link:

http://support.microsoft.com/default.aspx?scid=kb;[LN];207793
 
The database I am managing (I didn't
create it) is currently running as a single-user
scenario. The whole program, data & all tables
are kept on the server, but it's not split. We have
12 computers (users) that access this database,
and usually they are all in it at once. What we
want to do is break the users into groups and
put passwords on the "group" and give them
access to different information in the database
. . . what I'm looking for is a general idea on
how much work it is to do what we're trying
to do, . . .
Click to expand...

I've been in the computer business since 1958, still have quite enough
difficulty estimating my own tasks with full and detailed information in
hand, and wouldn't even _think_ about trying to estimate someone else's with
a general description.

You have two issues here... (1) splitting the database and setting up the
multiuser environment (pretty easy, in general) and (2) limiting the access
{no pun intended} of the users to particular information (which will be not
so easy).

In regard to issue (1), there's an introductory presentation on Access in a
Multiuser Environment that I did for my user group that you can download
from http://appdevissues.tripod.com. It will identify topics that I thought
worthwhile to discuss, and a bit more. The best collection of detailed
information and links on the subject of Access in the multiuser environment
is at MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm.

As for issue (2), this is a matter which can be addressed in several ways,
but all will, I think, require you apply Access' security. You'll need to
download the Security FAQ from
http://download.microsoft.com/download/access97/faq1/1/WIN98/EN-US/Secfaq.exe.
Be aware that Access' security is not _foolproof_, and that it is not
trivially simple. Read, re-read, study the FAQ and then ask questions.
Practice on some copies of simpler databases.

In addition to applying security, you will need to look at giving users
access to the data only by "Read with owner's permissions" Queries and
writing code to make their use with data limitations more friendly than
abrupt error messages about "permissions".

Larry Linson
Microsoft Access MVP
 
Back
Top