Specify which TO is the PTO in relationship graph

Idea created by mrwatson-gbs on Jan 6, 2016



    Sometimes the first TO (table occurrence) is not the TO you would like to be the PTO (primary table occurrence - the one that calculations are normally based on, and layouts are based on if you are using the anchor-bouy principal).

    This occurs ...


    • when (novice) developers use the first TO as a related TO and use a later TO as the PTO,
    • after restructuring a database and moving a table to a different file where a TO already existed.


    And it can cause problems, particularly when copying and pasting fields, because the fields calculation context is reset to the first TO


    Mand CH PTO Calc.png


    (There are I believe other errors related to this problem, e.g. after restructuring a DB when selecting a TO in an  Import Records script steps the TO is completely missing - but details fail me)


    In the current FileMaker correcting the problem requires a HUGE effort, because TOs and ALL references to TOs (fields, layouts, scripts, ...) have to be restructured. YUK!




    It should be possible to specify which TO is the PTO, i.e. the default TO for calculation context in field calculations.





    Use Cases


    • Adding a new table to a database
      • => It becomes irrelevant HOW you use the first TO (for related TO or for layout TO)...
      • => you can change the PTO later
    • Discovering that an old table has a false PTO
      • => You can fix it with a click!
    • Copying fields (to deployed solutions, etc)


    Consideration on internal implementation


    A possible downside to the idea: There is probably a very good reason, WHY filemaker uses the first occurrence as the default TO/PTO,... efficiency. Depending on how the DB is constructed internally, this change...


    • might make the DB a tiny little bit less efficient (because the pointer to the PTO has to be taken into consideration), or
    • may require a file format change in order to maintain efficiency, or
    • may require FMP to do a pile of internal restructuring when the PTO is changed.


    Only FMI - or maybe Winfried Huslik - can answer that!


    This is one of the ideas necessary for a more modular FileMaker