using text as a PK is generally considered a bad idea - if the text is changed, the link can be lost so it is importance to ensure that you enforce referential integrity in relationships and tick the cascade update related field box. Spaces or not are irrelevant - that relates to table and field naming conventions, not the contents
If your table is a simply a lookup list to restrict population options of a field in another table there is no need for an autonumber primary key, just use the 'name' field as the primary key (although the main benefit is not that it is a primary key but that it is indexed, no duplicates)
- then that table will be already have the information it needs so will never need to link to the lookup table in a query.
- The cascade as mentioned above will ensure all records get corrected for typos etc.
Hi Ajax, thanks for that. Will set my tables up accordingly. Cheers.
one other thing - if you were to type into the caption property of the symbolname field 'symbol name', then that is what will appear at the top of the column or an associated label to the field in a form or report when it is created.
That probably deserves a little more explanation.using text as a PK is generally considered a bad idea
- If the text can change, then yes, it should not be used as a PK
- But if the text is non-changing, there is nothing wrong with using text as PK. As matter as fact, many professional database programs use GUIDs as PKs, and those are text!
I myself create many PK ID numbers that are text.
So what it really boils down to is the important thing is to use a unique static, non-changing field. That is more important than whether or not the PK is text or numeric.