3 Replies Latest reply on Dec 15, 2012 11:52 PM by davidanders

    Can someone explain the architecture of FM 12 Pro - Starter Solutions


      Can someone explain the architecture of FM 12 Pro - Starter Solutions


           I am new to FM.  I've been going through the "Starter Solutions" given to create a new system.

           Each of the start solutions that has more than one table is using a similar architecture which I understand in concept but not in implementation.

           The each make use of a primary key called "XXX ID MATCH FIELD" in the main table of that particular app.  For instance:

           In the"Event Management" starter solution, this field is "EVENT ID MATCH FIELD".  This field is used to match records from associated files like "Contributors", Tasks", "Guests", "Agenda".  Each of these associated tables (1-to-many) has it's own primary key but is each connected through a many-to-1 relationship with the "Event" table.  This allows the user to see all the "Agenda" items for a particular event, all the Tasks items for a particular event.

           The relationship is fairly easy to understand if a record for an associated table (Agenda for instance) is created using a portal.  The foreign key ("EVENT ID MATCH FIELD") get filled in automatically.  Where I'm a little confused is this:

           Let's use the "Agenda" table for this example:  The "EVENT ID MATCH FIELD" is set to Auto-Enter as a calculated value which refers to a global variable called $$CURRENT_EVENT_ID.  This is where I get lost.  I'm know that global variables are set via scripts but how, when, where.

           WHAT I NEED:  I need to understand how to manage these global variables.  How do I set them?  When do I set them? Where do I set them from?

           The script is very simple but when and how do I call it.  I'd assume that I call it when a new "Event" record is created (trigger off the layout triggers - OnRecordLoad, OnLayoutEnter???).  I expected the OnRecordLoad to set the global variable $$CURRENT_EVENT_ID, but it doesn't.  Why not?  When does it get set?

           Is this is the only place I'd set the global variable?  Would I tie the trigger to a button that created a new "Event"  as opposed to using a portal?  

           The scripts used for each of starter solutions also use a global variable called $$SCRIPT_TRIGGER.  What's it's function?

           This question is already too long.  What I'm trying to understand is how to manage a global variable that ties different tables together.



        • 1. Re: Can someone explain the architecture of FM 12 Pro - Starter Solutions

               I've been looking at this for quite a while and I think I know how "most" of it is done.

               First of all, the global variable $$CURRENT_EVENT_ID is only being used by the iPhone/iPad layouts.  Why?  In the "Pro" layouts, all subordinate objects (like Agenda, Guest, etc...) are created using the portal.  And I guess that the system automatically fills in the foreign key and thereby overrides the formula set up to auto-enter calculated value of setting it to $$CURRENT_EVENT_ID.  I've watched the global variable and it's not even used unless you are using a layout for iPad/iPhone.

               So, why only in those views?

               I believe the answer is that the iPhone/iPad layouts don't use portals.  Maybe they think that they're not finger friendly.  So they use the global variable $$CURRENT_EVENT_ID to save the id of the current event so that on system can use that global variable to set the foreign key.  The global variable isn't used anywhere except to calculate the value for the foreign key during auto-enter.

               The methods that set the global are:


               §  Go to Selected Event | IOS

               §  Go to Task | iPhone

               §  Go to Contributor | IOS

               §  Go to Guest | IOS

               §  Go to Agenda | IOS

               §  Trigger | Create Event [New Record] | iOS

               §  Trigger | Sort Event Details | iPad



               This is all conjecture on my part since frankly, I don't know what I'm talking about.  Hope it helps someone else.  If I'm wrong, and you know what/why/how they are using these global variables, please chime in.


          • 2. Re: Can someone explain the architecture of FM 12 Pro - Starter Solutions

                 Actually, you seem to have perfectly figured this out. I'll fill in a few more details:

                 If no script has loaded the global variable with an ID, there is nothing for the auto-enter calculation to enter in match fields with this calculation. That's how the "override" works. In those portals, if you open manage | Database | relationships and double click the relationship line for the relationship on which the portal is based, you'll find that "allow creation of records via this relationship" has been enabled for the portal's table occurrence. (A table occurrence is what we call the "boxes" found on the relationship graph.) This option is what makes it possible to add new records in the portal when you enter data in a blank "add" row of the portal. And yes, FileMaker will copy the match field value from the parent record into the new related portal record when this happens to establish the link.

                 There are 4 commonly used ways to link a record to a record in a related table occurrence. You've spotted two of them in this starter solution:

                 1) Using auto-entered value from a global variable that is update via a script.

                 2) Entering data in the "add" row of a portal with "allow creation..." enabled in the underlying relationship

                 two more:

                 3) Selecting a value from a value list. Note that this is what happens in the Invoices starter solutiong when you select a product in the drop down in the portal. This links the portal record to a specific record in the products table.

                 4) A script can do the whole thing. Often, instead of adding records directly in the portal, the user clicks a button and the script copies the current record's ID number to a script variable, switches layouts to a layout based on the portal, creates the new record, uses set field to copy the ID number from the variable into the new record's match field and then returns to the layout where the new blank record appears in the portal.

            • 3. Re: Can someone explain the architecture of FM 12 Pro - Starter Solutions

                   If you  that is confusing you should check the design logic in StartingPoint (a free open template  that merges multiple starter solutions from ver11)
              Starting Point -  Contacts | Accounts | Calendar | Estimates | Invoices | Projects | Products | Staff etc.

                   For clear design logic (and naming conventions) I admire the free open database from yzysoft
              By yzysoft.com  Contacts | Products | Invoices | Letters
                   Sample Database -


              Filemaker Naming Conventions

              The White Paper for FMP Novices is useful  - 
                   Key Concepts in Filemaker 7 (PDF)