If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
#2
|
|||
|
|||
question creating multiple front-ends
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 |
#3
|
|||
|
|||
question creating multiple front-ends
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 . |
#4
|
|||
|
|||
question creating multiple front-ends
"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 |
#5
|
|||
|
|||
question creating multiple front-ends
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 |
#6
|
|||
|
|||
question creating multiple front-ends
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 . |
#7
|
|||
|
|||
question creating multiple front-ends
"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 |
#8
|
|||
|
|||
question creating multiple front-ends
"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 |
#9
|
|||
|
|||
question creating multiple front-ends
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 . |
#10
|
|||
|
|||
question creating multiple front-ends
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 . |
|
Thread Tools | |
Display Modes | |
|
|