You can't with this type of value list setup. (And I find this a frustrating limitation of FileMaker.)
There are several ways to work around this.
My favorite inverts the whole method by setting up an auto-complete enabled value list of just the names on a text field and then using a relationship based on Name to look up the corresponding ID in order to link records by ID. This requires scripted support to handle cases where you have duplicate names or when text is entered that does not match to any existing record, but the end result is far more user friendly.
Note that the "name based" relationship is only used to look up an ID. All other parts of the database then use the ID based relationship to access related records. This requires two Tutorial: What are Table Occurrences? for the same table in order to get separate relationships based on the two different fields (name and ID).
For a working example of this as well as other alternatives to a simple drop down list that also allow you to enter some partial text in order to "filter down" the list of values, see:
Please note that this is NOT what I recommended. Name based relationships are not a good idea. I break this rule in the example file for which I posted a link, but only in a very limited way. The name based relationship is only used during data entry to find the appropriate record which is then used to create the ID based link which is then used throughout the rest of the database.
Even with unique names, there can be problems. For example, you create a record for Jim Smith, link several hundred records to that record by "Jim Smith" and then discover that his name is really Jim Schmidt or Jim Smythe.... Or "Mary Andrews" changes her marital status and now her name is "Mary Johnson"...
I know what you mean, it was happened to another project 3 years ago.
I totally agree with you. The best way is never pull out other information only by their name. It should be combine or use a unique key, like SIN, health care number and the id like this. But mine are group names.
When you have a better solution, please share with me @ email@example.com
I already shared with you a link to file with multiple better solutions than what you are currently using. I've also describe one of those better approaches twice now in my responses to you.
While I used a person's name in my examples, the problem exists for any name based system where the user manually enters the text and you have to do this at least once for any "use values from field" value list. A data entry error that is not immediately detected and corrected creates problems for your relational integrity that are better avoided by not using a name based key for your relationships.
But I freely admit that when the value list of possible values is small, I don't always follow my own advice, but when I do, I also put in place a script for managing updates should such a correction need to be made.
SIN, Healthcare number and other externally provided identifiers also should not be set up as a primary key on which to base your relationships. They can be very useful in initially creating the needed links by internally generated ID values, but the very fact that they are generated outside of your database opens doors of vulnerability best avoided.
Thanks a lot