|
Question : multi-user MS Access Application
|
|
Hello all,
I am about to embark on my first multi-user MS Access Application. Before I begin I thought it best to reach out and ask for any suggestions that could help make the process easier and the end product most effective. My reference manual is Mastering Microsoft Access Development 2000 by Alison Balter. While I have done some research before hand most of this will be a learn as I go experiment. Thats where all of you come in. I posted this question with the intent of splitting the points fairly amongst all contributors. Of course, if one person answers all my concerns thats fine too. I also expect to be posting questions fairly regularly until the application is completed so there will also be plenty of opportunity for points.
This will be a credit request tracking system with seven end users. The team receives a credit request at a common email box they all work. The processor will enter in information about the request and update the record as the request goes through the process. Finally, the processor will close out the request and update the end resolution. The idea is to track who does what, how long it takes, how much credit is being issued and why.
They all have access to the same share drive so I plan to put the back end tables on the server and the forms/queries and such on each client. Im hoping this will be accomplished through developing one database with all the tables, queries and forms then using the database splitter I have read about. While each end user will be working in and updating a common table holding the information about the credit request, it is unlikely that a record will be updated by more than one person at a time. I mention this for suggestion on record locking.
Anyway, sorry for the long introduction but I think the background is warranted.
Any suggestions are greatly appreciated.
Thank you,
|
|
Answer : multi-user MS Access Application
|
|
1) Split the database into a Frint-end which will hold all of the forms, queries, reports, etc, and LINKS to the actual tables, which will be held in a 'back-end' (NO forms, queries, reports etc in the BE).
You will then be able to do either of two approaches:
A) Place a COPY of the Front-end on each users desktop, linked back to the Back-end which is on a common network drive which all users have access to, OR
B) Place a SHORT-CUT to the Front-end on each users desktop, keeping BOTH the Frone_end and Back_end together on the network drive, but the users only need to 'know' about the Front-end
The advantage of B) above is that it makes it very convenient to 'upgrade/modify' the application - you simply replace the old Front-end with the New Front-end, and each user gets the newest version when he/she opens the database from the short-cut. However, B) will increase network trafic, so that may or may not be an issue.
What other concerns do you have?
AW
|
|
|
|