but if this is a native Access table, that is not a requirement.
This I would question. I've seen many an action query in Access that would not work because there was no primary key on 1 side of 1 or more tables. Perhaps I'm not taking that statement in the correct context.
As for the initial question, I think what is of primary importance up front is to understand the implications of a decision. Where I worked, the CMMS based database was designed around PK
text fields. This means that wherever PK field DEPT was linked, you linked (for example) MACH to MACH (Machine Shop). That makes it so much easier when querying a PO table for example, because you didn't need DEPT table; otherwise you would because MACH would be some cryptic number such as 158 if it were an autonumber PK. Thus in a re-organization you could never change MACH to anything else, nor could you ever have a duplicate text value throughout the whole organization. In the unlikely event they ever HAD to change a text value for anything, they probably would have relied on cascade updates, although given the size of the db and the fact that the back ends were not Access tables, I doubt they were concerned about that.
For some, the whole concept might seem less than professional but I can assure you that the company was top notch when it came to IT, and was (and probably still is) a world class leader in computerized maintenance management systems (CMMS). I'm talking maybe 100 db's each with a huge number of tables, some with millions of records covering everything from soup to nuts (ICMS, RCA, FMEA, Purchasing, Safety, BOM, Contracting, Stores, Inventory, Maintenance, Scheduling, Utilization, real time condition monitoring, to name some). So the point of all that is that they are by no means amateurs yet use text based PK fields. That is why I say that the understanding of one's decision either way, replete with the limitations, advantages and any disadvantages of that decision is what's most important.
