bilbonvidia said:
I am trying create a very basic problem problem logging system.
This should, by all accounts, be an easy thing to achieve. But, by reading the next passage, it's clear that you are over complicating matters due to a lack of understanding in normalisation process. Thus you are duplicating stuff across tables and whatnot.
To my mind, what you want is to create the following tables:
tblEmployees
EmployeeID (Autonumber)
Forename (Text)
Surname (Text)
EmailAddress (Text)
Telephone (Text)
tblProblems
ProblemID (Autonumber)
EmployeeID (Number)
ProblemTypeID (Number)
StatusID (Number)
ImportanceID (Number)
DateLogged (Date)
DateResolved (Date)
tblProblemType
ProblemTypeID (AutoNumber)
ProblemTypeDesc (Text)
tblStatus
StatusID (AutoNumber)
StatusDesc (Text)
tblImportance
ImportanceID (AutoNumber)
ImportanceDesc (Text)
Where:
Table Name
Primary Key
Foreign Key
Field Name
(Field Type)
- The Employees table holds information about, you guessed it, employees.
- The Problems table holds all the information about cases reported to this helpdesk.
- The ProblemType table holds a list of different summary level problem type (e.g. Login Trouble, Forgotten Password, Software Request, etc.)
- The Importance table holds a list of different levels of urgency for reported problems. Thus your users can log a problem as per your defined levels: e.g. Urgent, Important, Moderate, Whenever
- The Status table holds a list of different positions for the reported problem. Thus you can keep track of a problem's status. e.g. Not Yet Open, Investigating, Handling, Awaiting External Assistance, Completed, etc.
Once you had these tables created, you would open the Relationships window and join like for like named field. e.g.
EmployeeID to
EmployeeID
Now that you have your relationships in place, the next step would be to make a query based on each table. Within these queries you can sort and manipulate the data anyway you wish. For example, when I use Employee tables I like to concatenate my employees' forenames and surnames into one field in the following format:
Smith, John. Easy to find, easy to read. You can't do this by linking a table to a form, just as you can't restrict the number of records loaded into a form when using a table.
Then make forms based on your queries. The important forms, of course, will be for the Problem Reporting screen. But that shouldn't stop you from using a switchboard to add in other forms for admin functions such as reviewing problems, editing employee details, and even problem statistics, should you wish.