You would get that error if you tried to change an existing number field to an
AutoNumber, but adding a NEW AutoNumber field should be no problem.

With your table in design view, insert a row at the top of the design
form.  Give the field the name of your table followed by "ID":
MyTableID.  For type choose Autonumber.  With that row/field still
selected, click the Key icon on the toolbar above the window.  That
makes MyTableID the Primary Key of this table.  Save your table return
to table view.  You will find a value in every row of the field
MyTableID.

As for the value of an autonumber datatype, its ONLY purpose in life
is to generate unique values to serve as a surrogate Primary Key.  Any
other use of the autonumber datatype will eventually lead you into
trouble.  It is not guaranteed to be sequential.

The content of that field should never be seen nor used by a human
being.  If it is shown troubles will come.

An earlier responder obviously prefers to use natural keys.  That's
fine people should do what they feel to be best.  The problem is that
the arguments he put forward don't address the real issues.:

====================================================
"I like my PKs to have some relationship to the data.  Something
like a SSN, or a company-generated PO # or Invoice #."

SSNs are poor primary keys.  They can be changed.   So can every other
single thing in a record including a person's name. This from a fellow
with the scars of battles fought, some won and some lost.  I've been
promised on the life of first born children that a certen element of
data "will never change".  HAH!  They never let me down, the promised
unchangeable element always changed.  Company-generated PO#s can be
altered after the fact due to human error. I solved the problem to my
satisfaction by always using autonumber Primary Keys.  Never again did
I have to sweat the primary keys nor waste the time formerly spent on
resolving issues thereto.

"Autonumber fields have nothing to do with our data and are more
difficult to work with than a field of our own choosing.  Yes,
there's more chance of error when the user is expected to
enter the PK manually but in practice we see no big source of error
here. The PK actually makes sense to the user so the user is more
likely to enter it correctly."

Absolutely!  Right On!  Autonumber fields have absolutely nothing to
do with anyone's data and that is their greatest value because they're
immune to all changes to do with the user's data.  Further, if you
never show it to your users, no one will ever be after you to change
it.  Google these groups for years past and you'll see lots of posts
seeking help in managing autonumber values.  In some cases it's just
that the programmer wants things to appear all neat and tidy (that's
really worrying about neat and tidy in the wrong places, expend your
efforts on the application because that's what you get paid to do).
However, in many cases, some control freak boss has seen the "ID"
label on a control and insists that the programmer jump through hoops
and make the autonumber behave per the control freak's whim of the
day.

IMHO, if you are using Autonumber primary keys and you require a user
to enter that autonumber value **for any reason whatever**, your
application is screwed up!  By their very definition, autonumbers are
generated by Access.  When that autonumber is referenced in a Foreign
Key, Referential Integrity takes care of it for you.

======================================================

If anyone is boxed in a corner and causing her or his users to enter
autonumber values manually to make an application work, please post
back into these groups expressing your problem and asking for help
resolving it.  That's what these newsgroups are for.

HTH