The use of the Primary table occurence for layouts and calculations is encouraged. For instance if you create a calculation that references a field in a related table, it will automaticly start with the Primary table occurence. If you want to base this on another table occurence you need to manually change this. If you forget it can lead to the wrong result.
Anchor bouy method of designing the relationship graph prefers that the anchor table occurence always be the primary/first table occurence. You don't have to use the layout created for you when the table is created. You can create any number of layouts based on this table occurence.
Hi Bruce, thank-you for your reply. In the FDC, they suggest that you should have a group of table occurrences that have no relationships to other tables. These are what I mean by Primary Table Occurences (see diagram from the FDC document).
I just noticed that this is in reference to using the Functional Table Occurence Groups (FTOG) Method. That being said I think this would be a good practice for the Anchor Buoy method as well.
Things have progressed a bit since that version of the FDC was written. There are number of papers available on different approaches to setting up your relationship graph. If you are using FM 12 and the new ExecuteSQL function, you don't need a relationship between tables to access the data, just a Table Occurence for the table you want to pull information from.
The naming convention can be very helpful in making your graph understandable. For example going back into it 2 years later and trying to determine what you had in mind when you developed it in the first place.
You might take a look at the suggestions in some of the available books out there. The FileMaker training series, Ray Cologons FileMaker Bible, The Missing Manual series. You could also look at Kevin Frank's blog http://www.filemakerhacks.com, and Matt Petrowski's web site http://www.filemakermagazine.com Both of these have useful information.
I disagree with the suggestion that each of the Primary Table Occurrences appear in the relationship graph alone, with no relationships, as in "figure 5." I subscribe to the anchor-buoy method, using each of the Primary Table Occurrences as the "anchor" for each Table Occurrence group.
As Bruce mentioned, "default" layouts are created based on each new Base Table (i.e., "Primary Occurrence"), and you can create as many layouts as you want, likely based on the Primary Occurrence of the layout's table. I can't think of any situations where you would use any other occurrence of the table, but there may be some tricks that utilize that possibility.
If all of your Primary Table Occurrences are isolated and whatever table structure you employ (anchor-buoy or otherwise), then even the "anchor" tables are "copies" of the primary occurrence. You'll see that frequently, when working with calculations, lookups, etc., in field definitions, you'll have to specify which table occurrence to use for the "context." In contrast, if the Primary Table Occurrences are your "anchors," the context is automatic and (almost) never requires your intevention.
I am not going to weigh in on the various methods of structuring relationship graphs, as I have used several different depending on the complexity of the file system. I note only that a unified graph, one without seperated sections, once tested as performing better than the others, but that's a tradeoff for some of the other benefits.
I believe that using the primary TO for a layout is a very good thing. It gives you the most direct access to the fields without requiring caching of related info in a served environment, and -- a biggie -- it gives you a layout from which to most cleanly import and export records from that table.
Importing and exporting from related layouts can be more challenging and more costly to the network.
Stephen, thank-you for figuring out what I was asking. I knew that there must be some valid use for the solitary primary table occurrences on the relationship graph as suggested in the FDC.
I am using these layouts for importing of data into the various tables and eventually this file will be served or shared.
Thanks again to everyone for their explanations.