question creating multiple front-ends

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

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" wrote in message
...
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

Hi Andrew,

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

Thanks!

-Amit

-----Original Message-----
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" wrote in
message
...
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


.

"Amit" wrote in message
...
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


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

-Amit

Oops, didn't see other reply.

At least we concurred!

TC


"TC" wrote in message
...

"Amit" wrote in message
...
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


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

-Amit

Oh, your response did help though
Thanks!

-Amit

-----Original Message-----
Oops, didn't see other reply.

At least we concurred!

TC


"TC" wrote in message
...

"Amit" wrote in
message
...
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


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

-Amit




.

"Amit" wrote in
:

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

"Tim Ferguson" wrote in message
...

(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

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

-----Original Message-----
Oops, didn't see other reply.

At least we concurred!

TC


"TC" wrote in message
...

"Amit" wrote in
message
...
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


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

-Amit




.

This is what you need:

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


"Amit" wrote in message
...
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

-----Original Message-----
Oops, didn't see other reply.

At least we concurred!

TC


"TC" wrote in message
...

"Amit" wrote in
message
...
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


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

-Amit




.