Splitting front end into modules

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

Guest

I currently have a database that manages all the info for our summer camp (sheduling, trips, meds, phonecalls, etc.). I am the only person who needs access to everything; everyone else only needs certain features (ie, the Health Center only needs the forms, reports, etc pertaining to medications). I was thinking about splitting the front end into different modules, rather than having everyone running the full database. Everyone would still access the same back end. Are the advantages/disadvantages to doing this? What should I watch out for? Any advice is appreciated
Thanks
Mr.Fuch
 
Mr. Fuchs,

The scheme you are considering could well turn out to be a real pain to
administer and maintain; multiple front ends will require as many FE
refresher customization, updates in common objects / code will need to be
made to all FE's using them etc.
An alternative approach you might consider is a common front end with all
functionality, but restricted user access to objects depending on their
needs. Access security is a good way to do this - though not the only one. I
usually use network logon name in order to implement user-specific
functionality (disabled or invisible buttons on switchboards etc.), while
the user doesn't even realize, since they do not have to logon to Access.

HTH,
Nikos


Mr. Fuchs said:
I currently have a database that manages all the info for our summer camp
Click to expand...
(sheduling, trips, meds, phonecalls, etc.). I am the only person who needs
access to everything; everyone else only needs certain features (ie, the
Health Center only needs the forms, reports, etc pertaining to medications).
I was thinking about splitting the front end into different modules, rather
than having everyone running the full database. Everyone would still access
the same back end. Are the advantages/disadvantages to doing this? What
should I watch out for? Any advice is appreciated.
 
Back
Top