>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.


>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".



>Each one has its own PK, so that any of it's children carry their unique DG_PK. Lets assume that each DG record can have multiple XX records. Each XX record would hold (at least) a FK_DG value to point to their parent PG record. We can get the XX children of a DG record as the XX records with a FK_DG the same as their parent PK_DG. The XX grandchildren of an NP records are all the XX children of DG records such that the DG is a child of NP. The uniqueness of reference is guarenteed because each record can only point to one parent! Now, even accidental duplication of fact-based keys preserve the uniqueness of reference.

Since I'm still in the dark a bunch, I not going to attempt the above paragraph.

Thanks
Elgin