3 Replies Latest reply on Jan 14, 2015 7:12 AM by erawson

    Global Tables

    amtrakpdx

      Title

      Global Tables & Connectivity

      Post

      Dear Wizards,

      As I’m lurking, I’m seeing the leaders making an argument (which I appreciate) for keeping the globals of a project all in one table.  I’m just getting used to the concept of ‘normal’ relationships (fk-pk, 1:many, joins) but I am at a loss as to how to connect these globals.  Does the global table even need a pk?  Is it to be an ‘Unrelated’ table?  I’m not able to find any examples on the web.  Any answers/guidance to that string of questions would be welcomed.

      TIA

        • 1. Re: Global Tables & Connectivity
          schamblee

          A global field is used for all records in the file and no relationship is required nor needed. A global table does not use a pk, there is no reason to link because it is available in all layouts.

          • 2. Re: Global Tables & Connectivity
            philmodjunk

            There are cases where it is useful to use a global field as a match field in a relationship. In those cases, you need to put the global field in a specific table. In all other cases, you can put the global field in any table in your file and it will still be accessible from any layout, script and calculation in that file due to the specified global storage.

            • 3. Re: Global Tables & Connectivity
              erawson

              I believe what he may have been referring to is the idea of using a table with a single record to store "Global" (not actual global) fields. We use this method in almost all of our systems to store configuration settings such as a container field to store the main logo displayed on reports in the system.

              These fields cannot be made global because the systems are almost always stored on filemaker server and as you know any changes made to a global field will be on a per-session basis and revert upon re-opening the file. Thus we store this in a table that only ever has a single record.

              The way we relate this table to all of the other tables is either using a cross join (aka cartesian or X join) or by defining a stored calculation field in every table called "constant" which always has the same value in every table which we can use to define an = relationship (e.g. Global::constant = Person::constant)

              Another option is to create a global field in the Global table for every one of the normal fields, then create a script that will run on First Window Open that sets the global field value to the stored field value, so that it can be accessed from anywhere without a relationship