Back to the basics.....

[chef_tim]

I'm starting over on my data base. What I am tracking is personnel and training tasks. I have apx 35 people and apx 75 training tasks, everything from weapons training to drivers training to carrer progression.

My first question is with tables and their relationships. Do I even need relationships for it??? Could I not just have one gig table and then use queries to create forms and reports???

I'm really struggling with the basics of what and whys of how relationships even work.

 

[chef_tim]

Thanks for the link Uncle. Some times it is good to go back and just re-examin the basics . I ended up exporting all my tables to Excel, and then reimpoting them to a new DB. That way I didn't lose any of my data, but I could start over with a fresh prespective. I think this one will be alot more functional, and it is even looking to be more athsetically(sp?) pleasing. Later and Thank again, Tim

 

[Sergeant]

This sounds familiar...

Tim,
In 2002, I was SOOO right where you are now. I had 75 aircraft mechanics in my section, and I was struggling to keep up with everything. I was getting daily beatings at the morning meeting. My first database was nothing but one big table...until I saw the light (that was about version 6 of my db). After a couple of months, I was the envy of my fellow section chiefs. Just stick with it and keep making improved copies until you get where you want to be.
I never did, however, track training tasks, just used the current skill level.
It seems you would need a tblTrainingTasks, tblPersonnel, and a tblTrainingStatus that links the two with SSAN, TASKID, DATECW. An entry in the tblTrainingStatus indicates the training task is c/w. When everyone's trained on everything, there would be 2625 (35*75) records in tblTrainingStatus.

Some things I learned along the way:
-Use SSAN as text w/o dashes to uniquely identify personnel in your tblPersonnel. (Primary Key) This helps a lot when (down the road) you decide to import data from existing systems (MIL-PDS, PC-3, whatever...).
-Make sure your personnel table only contains fields which uniquely IDENTIFY each person (SSAN, GRD, NAME, Service dates, etc...). Anything beyond that belongs in another table.
-One big revelation for me was the self-join. You can build a query with two copies of the personnel table on it and link the [sup'v ssan] field in the left table to the SSAN field in the right-hand table. Then FULLNAME from the left table produces the person and FULLNAME from the right table produces the supervisor. (If you want supervisor history, you will need another table to achieve this...tblSupervisor with fields like SSAN, SUPV_SSAN, FROMDATE, TODATE, etc...)

Feel free to PM me if you get stuck.

Sarge.