Hello John,
I created a field called PRIME and assigned that as primary key then I
assigned both the InvID and InvCntry as composite keys. When clicking the
indexs icon it displays Prime as unique while the other two fields allows
duplicates. The same set up applys with the Details Table. I went into the
relationship window to drag and drop muliple fields to the details table and
this resulted in 3 relationship lines of one to many. I cannot set the
(enforce referential integrity on the relationship) yet in testing data entry
within the invoices table it accomplishes what i needed...it accepts
duplicate invoices as long as a different country is entered and rejects if
same invoice and same country is entered.
INV-TABLE
Prime----PK-text
InvID---Composite-text
InvCntry--Composite-text
INV-DETAILS TABLE
Prime----PK-text
InvID---FK-text
InvCntry-FK-text
Is this what you were referring to or at the very least a hint of progress?
Again... *you are misunderstanding what a primary key is*.
It's PRIMARY! It is - must be - *unique* within the table. It can occur once,
and only once!
Therefore, it's appropriate to have it as the primary key of the INV-TABLE but
it is *WRONG* to have it as the primary key of the INV-DETAILS table. The
INV-DETAILS table should have its *own*, separate, independent, unrelated
primary key; it should have the PRIME field as a non-unique foreign key,
related to the Prime field in a one-to-many relationship.
What I had suggested is a multifield primary key:
INV-TABLE
InvID <Text, Primary Key>
InvCntry <Text, Primary Key>
<other fields>
INV-DETAILS TABLE
DetailID <Autonumber, Primary Key>
InvID <Text, matching INV-TABLE.InvID in size>
InvCntry <Text, matching INV-TABLE.InvCntry in size>
<other detail fields>
If you then open the Relationships window you can join InvID to InvID, and
join InvCNtry to InvCntry; enforce relational integrity and you should get a
one to many relationship.
Creating a separate Prime field is an alternative; it could be an Autonumber
in INV-TABLE, with a separate unique two-field index on InvID and InvCntry. In
this approach you would have a Long Integer Prime field as a foreign key (NOT
a primary key) in INV-DETAILS, and the InvID and InvCntry fields would not
exist in the details table at all (since that would be redundant, and they can
be found by linking to INV-TABLE).
How are you assigning a value to the Prime field anyway?