It will depend on the needs of your layout design. You may find that a second table occurrence of Software may be needed so that you can relate it to Software_Book instead of Software_Book 2. You can create such additional table occurrences, should they be needed, by clicking an existing table occurrence, then clicking the button with two green plus signs.
Ok, I didn't think adding a second table occurrence of SOFTWARE linking to SOFTWARE_BOOK would be necessary since it would be redundant? In addition to the above relationships on the relationship graph, I have added a second table occurrence or alias of the SOFTWARE source table to get the relationship:
SOFTWARE 2::kp_softwareid —> SOFTWARE_BOOK::_kf_softwareid.
Now that these relationships have been set up, let's say I wanted to do Finds from the SOFTWARE_BOOK Layout (which has its fields already placed on the Layout) of records contained in both SOFTWARE_BOOK and SOFTWARE_BOOK 2 table occurrences, then I should add related fields from SOFTWARE_BOOK 2 table occurrence and add them to the SOFTWARE_BOOK Layout? This way I can ask complex questions based on the information stored in these two table occurrences? I was not sure how making two table occurrences of, for example, the SOFTWARE_BOOK source table would effect doing Finds or Subsummary reports.
I'm beginning to see how FM works and how one can set up complex relationships by being creative with table occurrences and layouts with related fields.
Thanks very much Phil.
I would not place fields from Software_Book 2 on a layout that is based on Software_Book. Since both table occurrences (TO's) both refer to the same data source table, I fail to see the purpose to that. In fact, FileMaker would have to trace the relationship from Software_Book to Book to Member_Book to Member to Member_Software to Software to Software_Book 2 in order to determine what record would be used to supply the values seen in those fields.
Adding a 2nd TO of Software and linking it to Software_book would not be redundant. This would provide a direct link between these two tables that does not have to be traced back around through all the intervening tables and their records. It may or may not be useful to you, it depends of the design of your layout and scripts.
Here are a pair of threads on TO's you may find interesting reading: (The second link takes a pretty advanced look at TO's and FileMaker functionality.)
Ok great, thanks again Phil. I'm learning lots.