This seems like it should be obvious, but it's not clear how I would go about defining the relationships to accomplish the following:

I have a list of 200 or so numbered Functional Requirements.

I have 50 Technical Specifications documents, each one addressing any number of the 200 Functional Requirements.

I need to create a relationship whereby I can enter a Functional Requirement ID and see a listing of the Technical Specifications documents that address it. (There will be many Techical Specifications documents from the pool of 50 that address a particular Functional Requirement.)

I also need to be able to enter a Technical Specification document number and see a listing of the Functional Requirements that the Technical Specification document addresses. (Similarly, there will be many Functional Requirements addressed by a particular Technical Specification.)

Can someone please steer me in the correct direction to define this?

You need what is called "join" table between the two, with the ID of each of the entities. Their would be 1 record for each unique combination.

Then you can look into it from either side to see what you want. Actually, in v7 the names and all other information will be available by referencing the other table (occurrence), because the passage through the join file will link them.

If the Relationship graph looks like:

Requirements --> Join <-- Specifications

Thank you for your response. I've created what I believe represents your suggestion and I believe I've done something incorrectly. The relationship works fine in one direction, but seems to only grab the first record in the other direction. Attached is a file with the core functionality present. Can you glance at it and see what might be happening?

Here's the attachment.

Sample.zip

You have a repeating field that happens to be related to 7 records for the 9999 value. Then you have a non-repeating field that is related to only one record for the 105932 value. This is why you see 7 records in the first portal and only 1 in the second. Unless each repeating value has its own record, you won't see more than one in a portal. You could, however, not use a portal and just put the related field on your layout, formatted to display the desired number of repetitions. I'm not sure, however, that using repeating fields is even a good idea for your situation.

This seems way too simple for the solution not to be obvious. What am I missing here? If I have a "Combination" table that lists every specification and shows in a repeating field the requirement(s) that the specification satisfies, why does a portal lookup from two related tables, "specifications" and "requirements" not show the totality of each related to the other?

Portals show one line for each related record, not each related field. Your non-repeating field is only related to one record. It is related to each repetition in that field, but there is still only one related record, as the portal shows. That is why I said you will either need to give each repetition's value its own record and not use a repeating field or use the related field and no portal.

Sorry to be so obtuse about this. Your statement that "Portals show one line for each related record, not each related field. " was the missing piece for me. I was assuming that a portal would show each related field within each related record.

Your first suggestion of giving each repetition its own record and not using a repeating field makes sense to me, but your second suggestion is not obvious to me. In that, how I would accomplish this using a related field and no portal?

Basically drop the repeating fields. Turn on "Allow creation of related records" for Combinations. Use value lists for data entry.

TechSpecCross.zip

I second Fenton's statement. However, to answer your question, as I said before, put the related field on your layout, and (in Layout Mode) format it to display the desired number of repetitions. Select the field, then use the Format -> Field Format menu.

It's becoming clearer now. Thank you both very much.