Such generalized examples are often harder to figure out than the original problem you are trying to solve because we don't see the "big picture" and our suggestions may fail due to not taking that missing information into account.
Something is seriously wrong with your design here.
CustID Should, absolutely without exception be a unique value and it should not ever be allowed to change. A single field in your parent record should assign this value as an auto-entered serial number. If you are getting a customer ID of some sort from a source external to FileMaker, you should not use it as your ID value to link these tables.
I do not see any rational in your example for why customer ID = 41051 displays a CustData002 value for Florida in Record 1 and a value of Arizona in Record 4. That makes no sense here. It may make sense in your original situation, but I can't see why this would be so here. This discrepancy suggests that your tables should be related by some other field than custID unless this is a data entry error on your part.
Thanks for your response. The design worked for the original set of instructions, but fails now that the project has changed and I'm just trying to figure out the direction to go.
I realize that I should have explained this better.
Originally, this was a flat form that contained client information. Most client information, such as name/email/phone, doesn't change. The idea was that changing data would appear in the main table (Table B), while recurring information was placed in other tables (Table C/D) so individuals wouldn't repeatedly have to enter it in. These tables were are by CustID.
Table B represented user inputed data. The Florida/Arizona was just to show that it was random, but probably not pertinent to the issue at hand.
Tables C/D are assumed to be recurring information. In Record1, (under normally situations) I'd want that information to appear each time that the user typed in CustID=41051. However, in Record4 something changed. I need to create a new (CustID=41051) record in Table C to reflect the fact that Canada is now an option.... so I'm assuming that I have two records relating to '41051' now, one for 'China' and the other for 'Canada'.
I no longer have the one-to-one relationship that I have before using the CustID as the unique identifier.
So that are basically two issues
(1) Attributes (Tables C/D) will occasionally change, but must be associated with the corresponding correct record in Table B
(2) The last/most-recent occurrence of attribute (Table C/D) will be used as the recurring data to populate future records as in Table D, Records1 and Record4.
I hope that explains the situation better.
It helps, but doesn't explain why you want a second record with the same customer ID number instead of just editing the existing record with the new data.