General Help

[Andyjones]

Hi

I have a spread sheet that is like a engineer checklist to see who is in who is covering etc, and I am trying to turn it into database I need help with the tables here are the fields in the spreadsheet, and I need to know if it can be done all from one table or would it need to be seperate table.

Area Eng Branch Region Area Eng Comments Covering engineer Mobile numbers not or incorrect on JDE

The covering eng can be the same as the area eng or a different engineer that we decide to enter into the table, the checklist does not contain engineer names just engineer numbers ie 50001234.



Please advise also on how the relaionship would be set up. just need help with the table design at the moment.

[rpeare]

Are you interested in keeping a history is this just for 'this week' or 'this month'. In other words are you going to be overwriting data or keeping a history?

If you're just interested in the 'right now' (whatever your current period is) you can probably do it it 2 tables.
One table with all your engineers (autonumber field as your PK) this would hold your engineer numbers names, contact information, etc.
One table with all your branch/regions and you'd just update the area engineer and covering engineer as it becomes relevant.

If you want to keep a history that's a little more complex and would likely involve the same two tables but your branch/region table would have a PK (autonumber) of it's own then you'd likely have to have a third table that stored your branch/region PK, the AreaEngineer (FK to your employees table), covering engineer (FK to your employees table as well) and the date range the employees are covering that branch/region.

That would be probably the minimal table structure.

[Andyjones]

Well some of them remain Historic as a vacent area eng will always be on there so it would be for both history and then and now

[Dal Jeanis]

Andy - go do this quick tutorial on database design, http://www.rogersaccesslibrary.com/forum/topic238.html, do a couple of the practice examnples, then do an entity relationship diagram for your database. That will tell you how many tables you need.

You'll save yourself dozens of hours of headbanging if you spend a couple of hours on understanding proper design.

Then come back and ask us very specific questions about your proposed design.

[rpeare]

I don't understand if there is a question in your last response or if you are stating something.