Split database: Can you have different front ends?

[bo8482]

Hi all
I have what is now a pretty humongous database in that it has many different forms/reports.

Naturally with so many forms and reports I don't want users feeling overwhelmed by the amount of data entry, or else forgetting to fill in certain forms.

As I'm splitting my database anyway (it's to be shared over a department network), can I tailor make different front ends depending on the user needs so that they only see the forms/reports that are relevant to them? Is that possible? And if so, are there any practical considerations to think of? (eg. if i change tables at a later date is that going to be a big deal?)

Thanks for any tips you can give me

 

[Rabbie]

Yes you can have different Front Ends. It will increase your Admin load ensuring that each user gets the right FE for them but there are tools out there which can help you.

 

[Mike375]

It is one of the reasons I have a DB on a network, different forms etc for different people.

But as Rabbie said you can get your self in a knot if not careful.

 

[bo8482]

Thanks for the reply. Can you recommend any tools for this? On another point, is it worth shelling out for those Access Analyzer programs?

 

[gemma-the-husky]

although you can do it, would you really want to - i dont think you would want more than 2 or 3 variations at the most, and I dont think you would want any user to need more than 1 version

you should be able to get appropriate functionality by using security settings - otherwise you are in danger of needing to duplicate any improvements over multiple database front ends, wihch is quite tricky

its a bit like wanting to give certain users a scaled down version of excel or word

 

[DCrake]

I wrote a full blown manufacturing system for a company that had several departments

Stores
Injection Moulding
Production
Inspection
Management

Each one had their own module front end

I split the back end into two different ones

One that contained the tables that changes on a dailly basis
One that contained the lookup tables which changed seldomly

Each front end had links to the tables that pertained to the department
The managment mdb had links to all
The management one could open any of the other mdbs

This meant that each front end only contained their forms
This was easier to manage and cut down on the size of the whole system considerably

David

 

[Lightwave]

I could see that its one of the real benefits of being able to split the database.

 

[gemma-the-husky]

I could see that its one of the real benefits of being able to split the database.

no thats not why you split a database, although it is a beneift

you split the database, because the data should be distinct from the application, and to give each user a unique copy of the application

in a multi user system this is vital, as users should not be using the same front end, as this is prone to causing corruption.

in a single users system this doesnt matter so much, BUT

with a split database, you can then modify the functionality of the application without worrying about how to deliver those improvements (incorporate them into your dbs), because the functionality is separated from the data.

 

[Atomic Shrimp]

You can have different front ends, but I would tackle it differently - maybe by creating a table of users, getting the user to log in on opening the front end, then taking them to a switchboard form, where you could have all the buttons hidden or disabled by default, only enabling those appropriate to the type of user.

That way, you're only ever managing one set of forms, with no gaps or overlaps - and one set of links to the back end, one set of custom functions in your module, etc.

I think the only time I'd ever really consider maintaining two distinct front ends would be if one of them only needed a single, very simple enquiry form, and the other one was really, really big - but that's just my personal preference.

 

[gemma-the-husky]

i tend to agree with Mike

the problem with having multiple front ends is that if you modify a function in one, you need to remember to propagate this through all the variant copies. You may be able to overcome this to some extent by having a common library, but you may not be able to handle all the functionality with shared library functions.

----------
you get a similar thing if you distribute a standard packaged application. if a particular user wants a "special" modification, its better to find a way of incorporating the mod in your standard system, then having the nightmare of maintaining multiple variant systems.

 

[Rabbie]

You can have different front ends, but I would tackle it differently - maybe by creating a table of users, getting the user to log in on opening the front end, then taking them to a switchboard form, where you could have all the buttons hidden or disabled by default, only enabling those appropriate to the type of user.

That way, you're only ever managing one set of forms, with no gaps or overlaps - and one set of links to the back end, one set of custom functions in your module, etc.

I think the only time I'd ever really consider maintaining two distinct front ends would be if one of them only needed a single, very simple enquiry form, and the other one was really, really big - but that's just my personal preference.

The other scenario when I might consider different front ends is to have a standard front end for all ordinary users and a separate more complex frontend for use by the system administrator but then it might be better to use the security functions to restrict access to functions on the basis of what they needed.