6 Replies Latest reply on Nov 5, 2012 12:02 PM by JayIchiyen

    Primary Table Occurences - what should and shouldn't you use them for.

    JayIchiyen

      I have been planning out a solution and starting to add tables into the Relationship graph. FileMaker Pro automatically generates layouts based on your tables and since I have been creating the Primary Table Occurences (PTO) first, the layouts are based off these table occrurences.

       

      Is this a bad thing?

      I guess the same question applies for value lists too. Is it good practice to have value lists based on the primary table occurence of a table?

       

      My understanding of the use of Primary Table Occurences, according to the FileMaker Development Conventions (FDC) is that their main use is for "internally referenced" calculations. Which leads me to my Third question; Is there a newer version of the FDC document other than the one dated November 1, 2005 (just after Filemaker 7 was released).

       

      Thank-you in advance!

        • 1. Re: Primary Table Occurences - what should and shouldn't you use them for.
          BruceHerbach

          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.

           

          HTH
          Bruce

          • 2. Re: Primary Table Occurences - what should and shouldn't you use them for.
            JayIchiyen

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

             

            relationshipGraphPTO.JPG

            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.

            • 3. Re: Primary Table Occurences - what should and shouldn't you use them for.
              BruceHerbach

              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.

               

              HTH

              Bruce

              • 4. Re: Primary Table Occurences - what should and shouldn't you use them for.
                ErikWegweiser

                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.

                 

                FileMaker Pro AdvancedScreenSnapz003.png

                 

                 

                 

                 

                 

                 

                 

                 

                 

                 

                 

                 

                FileMaker Pro AdvancedScreenSnapz004.png

                • 5. Re: Primary Table Occurences - what should and shouldn't you use them for.
                  Stephen Huston

                  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.

                  • 6. Re: Primary Table Occurences - what should and shouldn't you use them for.
                    JayIchiyen

                    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.