John may have gone to bed by now. I'll give you my take which is
probably in line with his: If not, I'm sure he'll pick it up in the
morning.
You need *one* table for the data you are collecting. In that table
you should have fields for
student identification
login date default value format(now(), "pick a format")
login time default value format(now(), "HH:mm:ss")
(don't know why you might need start and end
times. *You* already know when the classes
start and end, This doesn't detect a student
logging in for a wrong period.
The prose you want in the table would most likely be entered by you at
a later time using a Form. Once your design is complete, always use
the forms you have designed to manage your data. Never go directly to
the tables to manage data. All of the other information relevant to
the student's logging in/scanning in is already known to you: Which
classes meet on which days and times and which students belong in
which you already know. You should have all of that other information
stored in other tables.
Tables are used to store information about entities. Tables are named
for the type of entity whose records they store. Every entity of that
type belongs in the same table. Only information about an entity
belongs in a record about that entity. Don't be afraid to use more
tables when there is good reason to do so. Never use a table to
differentiate values of an attribute of an entity. For example:
Tables named tblBlueCars and tblRedCars is a way of storing data in
table names. They are poor choices. The real entity type in this
case is "Cars". The color a car happens to be should go into a field
named something like "color" and could take on any legitimate color
value. Only one table; tblCars to store all car entities and one
field to indicate the color of the car that this record is about.
John usually gets it said with fewer words.
Advice: Visit
www.mvps.org/access and read about the 10 Commandments
for Relational Databases. It's all true. Continue reading about the
fundamentals of designing with Relational Database Management Systems
until they make sense to you.
HTH
