There is no need to combine the two in a table. You can combine them in a
text box or in a query if necessary. If you mean that you need to see a
listing of who holds a particular type of badge, then it sounds as if your
situation is that each employee can have many (i.e. more than one) types of
badges, and that each type of badge can be held by many employees. In that
case you would need an employees table, a badge table, and an EmployeeBadge
table.
tblEmployees
EmployeeID (primary key, or PK)
LastName
etc.
tblBadges
BadgeID (PK)
Description
etc.
tblEmployeeBadges
EmplBadgeID (PK)
EmployeeID (foreign key, or FK)
BadgeID (FK)
DateReceived (or other information specific to the specific badge)
The FK fields need to be the same data type as their namesake PK fields, or
with the data type set to Number if the PKs are Autonumber. (Aside to
anybody who wants to tell me that Autonumber is not a data type: that is
what they call it in table design view.) Designate PK fields in table
design view. In the Relationships window, establish relationships between
the PK fields in tblEmployees and tblBadges and their namesake FK fields in
tblEmployeeBadges. Click Enforce Referential Integrity.
Build a form based on tblEmployees or on a query based on tblEmployees, and
build a subform based on tblEmployeeBadges (or on a query). In the subform
bind a combo box to BadgeID, and use tblBadges as the combo box Row Source.
Once the badge information is entered you can build a form based on
tblBadges, with a subform based on tblEmployeeBadges, to see who holds a
particular type of badge.
This procedure assumes that you also have a form based on tblBadges that
lets you make a listing of badges. You will do best to have the listing
before adding a badge to an employee's record.
By the way, when you use nonconventional abbreviations such as "infor" it
makes the question hard to read.
