... Each record in the table contains the employee name and yes/no check boxes for each of the 20 or so classes that is taught as to whether they are required by the employees job function...
Before you begin to get involved in form/report design, I would suggest you rethink this table design. This is going to continually cause problems when you try to design/implement other aspects of your application in the future.
If you go to
this page you will find some good information on this specific problem (using check boxes to store choices), but I would also suggest you do some research on relational design and normalization. What you have is a many-to-many relationship between Employees and Training, or perhaps Job Types and Training. You need three tables to properly model this relationship.
As an example of what i mean by future design problems, let's suppose that a new training class gets added to the mix at some point in the future. With your current design you will need to do the following;
1) Add the additional necessary fields (check boxes) to the table (which is really data, not fields).
2) Redesign every query that uses that table as a record source, selecting the additional fields and adding additional criteria to the where clause.
3) Redesign every form or report that uses any of those queries (or the table) as a record source, adding additional controls to represent the new choices.
4) If your application uses any VBA or macros that that reference the certification type fields, you will need to find all those instances and rewrite that as well.
5) Probably a few other things that aren't coming to mind right now.
Situations like this can quickly become a design nightmare. It would be better to correct this early in our overall design process, rather than later.