Hi Dave,
If I understand your post correctly, you currently have
separate columns (fields) for each question number,
similar to what would be laid out on a spreadsheet. This
type of layout will be very difficult to work with down
the road, and will not be very flexible for future
surveys (if that will be a consideration).
A much preferred way of setting it up would be to have a
table that has a field for Employee ID, Survey ID (if you
will ever have other surveys), Question No, and Answer.
You would then have a related table listing all employees
(and if you were doing large numbers of surveys you would
also likely have lookup tables for surveys and question
numbers and maybe even answer ranges, but for now it
sounds like you don't need that).
Having your data structured this way, such that all
question numbers are in a single field and their
corresponding answers in another field, makes it very
easy to group by answer numbers and count results. It
also makes it fairly easy to do slightly more advanced
calculations and expressions such as your desire to
return the total number of records for each question
number, without having to write expressions for every
single question number.
I recommend a table structure something like the
following:
TblEmployees
EmployeeID (AutoNumber)
LastName (Text)
FirstName (Text)
....Any other employee Data you may need.
TblAnswers
EmployeeIDRef (Long Integer)
QuestionNo (Byte or Integer)
Answer (Probably Byte - depends on your range)
....You may also need SurveyNo if you will be doing
multiple surveys.
Then, in the relationships window define a relationship
between the EmployeeID and the EmployeeIDRef. You
probably should double click the relationship and check
enforce referential integrity to prevent invalid
EmployeeID entries.
In TblAnswers for the EmployeeIDRef field you can use the
lookup properties to specify TblEmployees as the lookup
source to give you a drop-down list of employees (set the
number of columns = three to display the names)
This structure will make your life much easier down the
road. If you get into looking at doing a lot of surveys,
I know that I have seen some of the MVP's post links to
sample survey databases that show recommended ways to
handle surveys. You could probably find these by
searching for survey, but post back if you can't and I
can try to find one (if you are interested).
Once you have this structure you can try my earlier
recommendation for the query setup, but post back if you
need help.
-Ted Allen