question re: creating multiple front-ends

[Amit]

MS Access 2K, Windows XP
========================
I have a database which is to be used by multiple "groups"
of users, and each group may have different reports and
some variation in forms. So, I'd like to split the
database into a BE and FE, with different copies of FEs,
one for each group, linked to the same BE.
==========================================================
I have two questions.

First question is: how do I create multiple copies of FEs
after splitting the database?

a. copy-and-paste the FE created after the split, or
b. create a new empty database (FE) and then import tables
from the existing FE, and link it to the BE, or
c. any other?

Are both a. & b. OK? Or, is one preferred over the other?
Any advantage of one over the other?
==========================================================
Second question is: Should the FEs be placed on the
individual desktop of all the users, or on the shared
drive? The BE is on the shared drive.

Thanks for any help. This is the first time I'm creating a
multi-user, multi-FE database.

-Amit

 

[Andrew Smith]

Amit,

The easiest way to create multiple front ends would be to copy and past the
original front end, and save the copies with different names. This saves you
the trouble of importing the objects from the original front end.

HOWEVER, I doubt that having multiple front ends is the best way of tackling
this problem. You will have much common functionality between the front
ends, and will need to ensure that all are kept up to date - ie if you
change one common form or module then you will need to modify it in several
files rather than just one. It will be very easy for things to get
unmanageable.

I think it would be better to go with just one front end, and hide the bits
that are not relevant to each user. You could create a user table to
identify which group each user belongs to, and then modify the appearance of
the database according to who is logged on. This might be a bit more work to
start with, but would be much better in the long run.

However you do it, each user should have their own copy of the front end on
their local drive.

 

[Amit]

Hi Andrew,

Thanks for your prompt response. What you wrote makes
sense, and I'll try to implement it that way.

Thanks!

-Amit

 

[TC]

MS Access 2K, Windows XP
========================
I have a database which is to be used by multiple "groups"
of users, and each group may have different reports and
some variation in forms. So, I'd like to split the
database into a BE and FE, with different copies of FEs,
one for each group, linked to the same BE.
==========================================================

Splitting the db is a good idea for other reasons also. For example, if the
db is >not< split, it is difficult to roll-out new code versions without
overwriting the user's data. With a split structure, you just copy a new FE
over the old FE(s), and the users' data remains unchanged in the BE.

But, aren't you heading for a maintenance headache if you have two

different< FEs? What about the programs that must be common (unchanged) to

each FE? You run the risk of accidentally having different versions of those
programs. personally, I would try to incorporate >all< the necessary
functionality into >one< FE. For example, when you called a report from a
main menu, the main menu code could pick from several different versions of
that report, depending on the logged-on user's name,. group membership, or
whatever.

I have two questions.

First question is: how do I create multiple copies of FEs
after splitting the database?

a. copy-and-paste the FE created after the split, or
b. create a new empty database (FE) and then import tables
from the existing FE, and link it to the BE, or
c. any other?

Are both a. & b. OK? Or, is one preferred over the other?
Any advantage of one over the other?

a. is fine AFAIK. Of course, after making changes in a FE, you would always
compact it and do a "compile all".

==========================================================

Second question is: Should the FEs be placed on the
individual desktop of all the users, or on the shared
drive? The BE is on the shared drive.

Put the FE(s) on each individual desktop. Or, if you put it/them on the
server, there must be a >seperate copy< for easch user, strange as that may
seem. IOW, multiple users >must not share< the same copy of an FE.

HTH,
TC

 

[TC]

Oops, didn't see other reply.

At least we concurred!

TC

 

[Amit]

Oh, your response did help though
Thanks!

-Amit

 

[Tim Ferguson]

I have a database which is to be used by multiple "groups"
of users, and each group may have different reports and
some variation in forms. So, I'd like to split the
database into a BE and FE, with different copies of FEs,
one for each group, linked to the same BE.

Well, just to provide a counter-argument, I am all for giving users the
interfaces they need. For example, lowly data entry clerks need full read-
write access to everything, while high up management need a restricted,
read-only, top level view of summary data.

For my money, the maintenance headache comes in trying to keep a single
large mdb running with 72 different reports and forms. Jane wants a change
to hers, which breaks something else that only Eric needs, so he sticks
with the previous version, and so on. Zandra can never find her reports
because her position in the alphabet always means they have scrolled off
the bottom of the database window. And so on.

On the other hand, letting people have a small, fast mdb that only does
what they need means that they just don't need updates so often. And you
can use appropriate platforms: some db applications just sit better in
Excel than others, and Word is often a better report writer than Access
will ever be.

Storing and re-using common code is not too much of a problem, with a
decent version-management mechanism; particularly if you can use Class
modules and get everything abstracted.

Second question is: Should the FEs be placed on the
individual desktop of all the users,
Yes

or on the shared drive?

No.

Hope that helps


Tim F

 

[Guest]

I am from the Access support department at http://www.enterpriseprojectconsulting.com and we would be happy to assist you in resolving your issue

Thank you

Enterprise Project Consulting

 

[TC]

(snip)

Well, just to provide a counter-argument, I am all for giving users the
interfaces they need. For example, lowly data entry clerks need full read-
write access to everything, while high up management need a restricted,
read-only, top level view of summary data.

Giving "high up management" ANY view of the data is a seriously misconceived
idea IMO!

TC

 

[Amit]

One follow-up thought.

If I install front-ends on each desktop (as opposed to on
the shared drive), this will entail going to each desktop
and updating all front-end every time a change is made. I
guess more physical activity is good for whoever will do
the maintenance

-Amit

 

[Andrew Smith]

This is what you need:

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

 

[Amit]

Aha! The virtues of being selectively industrious
Thanks much!

-Amit

 

[Guest]

I put a small VB program (actually in Access) that each user runs each day before they use the main database. This program copies a fresh copy of the front-end from the server to their computer each day. That way if I make an update to the program each user will get the update. It always eliminates the need to compact the front end since they are getting a new, compacted database each day.

 

[Tim Ferguson]

Giving "high up management" ANY view of the data is a seriously
misconceived idea IMO!

<VBG>

Tim F