Software

I would say this depends on how many people will be editing the data in this file. Are you going to have multiple users accessing the database at one time? If so, I would try splitting the database to front/back ends. Should be under tools/database utilities/database splitter... though I'm not 100% sure on Access 2000. Save the back-end file to a mapped network drive. Then you can distribute the entire front-end file to the juniors (who will have to have the same drive mapped, and sufficient permissions to write to the back end file on the network).

If simultaneous multiple user access isn't an issue, I would say that you would probably be fine shortcutting to the database. Note that you will create higher network traffic this way, but it should be minimal. Also, you may want to consider implementing some User-level security to limit the Junior PM?s access, but that can get VERY complicated.

I'm not sure what all your PM needs to do with this data, but it sure seems like a shared Excel spreadsheet would be a more simple solution. To do this database correctly, you may run into some difficulties in implementation. The main thing that concerns me is the follow up dates. Do all the projects have the same number of follow up dates? Or this a dynamic thing, based on project? If they are dynamic (as almost ALL projects are at my job), you may have some issues. I'm not sure what the specific requirements are for your PM to manipulate this data would be (reporting, queries, etc.), so perhaps a d/b is the only way to get it done.

Good luck, and hope this helps.

There are several ways to do this, neither is easier than the other, but there are definite benefits and problems that come with each solution.

Before you start, it is usually good practice to separate your data from your application. If the database remains as one file, you will need to boot all users out while you make programming changes etc. If the front end is separate, you can work on this and users can still access the data via their current front end app. The back end contains only the tables and resides on the shared drive. The front end contains everything else + a link to the tables in the backend database (make sure you connect them with UNC rather than Drive letter paths, eg: use \\server\share instead of X:\). The front end can then reside anywhere as it will always point back to the one data source.

Having the users open a single instance of an access database in a shared environment works ok, but MS Access is resource hungry over a network so you may experience slow open times.

Once you have isolated the data into its own back end and reference it from the front end using a UNC path, you have the freedom to run the front end database from the same network location. If you find it is slow, just get each user to copy the front end to their local machine.

You may run you into problems when you need to update the version having multiple front end copies though. These are just some of the basics, hope it helps...

This question was closed by the author