This is a "rule" to be broken with great caution. The ideal primary key is:
b) never ever changed once assigned
c) implemented in as simple and "bullet proof" a fashion as possible.
The names of states are certainly unique. And it's very unlikely that a state would change it's name (though I suppose not impossible.)
BUT, there's another scenario that comes into play that results in having to change primary key values when you use a "name" value: Correcting data entry errors. If a name get's misspelled during data entry and you do not discover the error right away, then you are back in the unwelcome situation of having to update first the foreign key fields that link to your primary key and then to update the primary key without "breaking" the connection between parent and child records.
So with a table listing 50 states by name, there is a small chance that you could mis-enter the name of a state in that table. But the chance of this seems small enough that I would not have a problem using names in such a table--though some might well disagree.
So yes, this works, but look before you leap. ;-)
Thanks again for the help. It seems like a fairly safe move with states, but less with countries. I was hoping to reduce the amount of work I needed to do in setting up the relationships for these tables.
Am I wrong to think that the inability to auto fill value lists from the second value is an important design flaw in Filemaker Pro?