Relational lookup fail

I have 2 DB’s related to each other by first and last names. The relationship has worked perfectly for years: when I type a name into the subsidiary DB that occurs in the main DB, the subsidiary DB record is populated by the information from the main DB. Nothing fancy at all.

Today I typed a name into a new record in the subsidiary DB and it created a new record in the main DB, ignoring the record already existing there. This has never happened before with this particular name, though I have gone through this process with this record at least 10 times since moving to PanX. I have checked for unexpected spaces in the name; I have successfully searched the name in the main DB; I have pulled the fields in that record into a formula workshop successfully (First+" "+Last returns that person’s name just fine when the record is up). I even brought the offending record up in the main DB and successfully searched the information in the formula workshop of the subsidiary DB with the main DB chosen in the workshop DB dropdown menu.
I entered 3 other names into the subsidiary DB today and the related information was brought over from the main DB just fine. Only with this one record is there a problem, and as far as I know nothing in that record in the main DB has been changed since I last performed this operation with it last January.
Can anyone suggest something I might have missed?

You haven’t really told us anything about how your system works, so we’re not really going to be able to assist you. You must have some procedure that is being triggered, but without being able to know what is in the procedure, no one here can know what is the cause of this behavior.

Try comparing the first and last names in both records. Just see if «First Name» = «First Name» and «Last Name» = «Last Name» in both databases. Spaces are not the only invisible characters that could cause an inequality.

Using Gary Y’s Reveal Invisible Text utility (which I was finally able to download), I discovered a random Tab character in one of the DB’s. Thanks, Gary!