>>You're putting the cart before the horse. If we have a parent table NP, and we add a field as a unique code to it called PK_NP, and integer that is the unque id for the record. Each child record, instead of holding CustId and UPSIno, which point at the parent, can hold a pointer to their parent called FK_NP, and each then have their own DG_PK, or LQ_PK, which is an integer that is separate from and independent of the FK_NP value. How does this work?
>
>I understand that I need to add the PK_NP field to Nameplate and use it as the primary key, then add the FK_NP to the DGA and other child tables and use those as the link back to the parent. But isn't the only way to determine which parent records are linked to the child table is by using the current fields that make each nameplate unique. I don't understand how once I assign the value 12345 to a nameplate record as the primary key I am going to find all the children for that parent based on a PK of 12345.
>

Yep, but you basically have to add the new PK to the parent, populate it, then descend to the child, add a PK there, and then add an FK to point to the parent that, using the composite key information now in the child, link to the parent. That each parent is unique is adequate to do this. Your only link 'up' now is via the composite key, and in the event that the composite now available to the child to find the parent is not adequate, you need to go back and, given multiple indentical candidates in the parent from the child's standpoint, pick the right one.

IOW, It's the problem of establishing who dad is when all you know is it was a redheaded gut from Hoboken; you line up the possible suspects, ask "which is the one?" for the child with incomplete information, and go from there.

IOW, the flaw of the existing composite key is not in the table that has an inadequately-unique candidate composite key for the table - each record in it is unique, and given a factless key for the table, I can construct a valid primary key for the table, the problem is everyone who needs to point at it and only has the inadequate key to resolve things.

>
>>If I'm on a given NP record, whose NP_PK is 12345, the Children of this record in DGA are the child with a value of FK_NP = 12345.
>
>How do I know which existing child records to assign FK_NP=12345 to without basing it on the existing methods of relation "custid+sampleno".
>

You've found the problem - the problem is not having a factless key, it's with correlating it from the child perspective.