I will go into each of them and set an autonumber for the primary key.

However, by adding the primary keys does this by its very nature mandate I
perform other functions in the forms, queries and reports I have already set
up so as not to compromise the integrity of the newly updated database?  If
the answer is yes, if you could kindly walk me thru the steps of the update
required for the forms, queries and reports.

I agree with Rick Brandt to some extent, and I can't think of any real
problems that you might encounter by adding Autonumber fields that you
never use, so you perhaps should go ahead and stick them in there (in
case you later need them) and nothing will go wrong, although they will
make your Tables (and thus the database file) slightly larger and
require you to name them and keep track of them.

However, the goal of a "properly designed database" is not, IMHO, a
sufficient reason all by itself for doing something.  If you've been
given an assignment in class or by your boss to produce a "properly
designed database" according to some set of rules, then OK, you do what
your customer requires.  Otherwise, it doesn't hurt to know the reasons
for making some choice.

In this case, one such reason for ensuring that all the records are
easily distinguishable (by having a unique primary key field in each
record) might be that the Table is part of a self-join.  For example,
you might have a bunch of [Employee] records in which there's a field
indicating who the supervisor is, and the supervisor's record is also in
the [Employee] Table, so that the [Supervisor] field is a pointer back
to another record in the same Table.

In other cases, you may never define a Query which would make use of a
primary-key field in some Table, so such a field would just sit there
occupying a small amount of space and taking a small amount of extra
time when you add records to the Table.  As I said in another message,
you can always add the Autonumber field later if you need it, but Rick
is probably correct that it won't hurt anything to add it now, even if
you never use it, and you won't have to worry about it later on if you
take care of that now.  But suggesting that a Table that doesn't have a
primary key is somehow useless makes no sense to me, absent some
practical reason for putting that key there.

  -- Vincent Johns <vjohns@alumni.caltech.edu>
  Please feel free to quote anything I say here.