3 Replies Latest reply on Feb 18, 2011 10:49 AM by philmodjunk

    Globals - when, how, where?

    basilisk2

      Title

      Globals - when, how, where?

      Post

      I've been wondering for a while what typical uses Globals can be put to. I understand they are fields that are independent of relationships or tables, and that they have to be on a layout for that layout to use them, but that's just theory. In practice I'd like an idea of their potential uses because I can't work out what to do with them.

      Do they substitute for something, are they special links or relationship definers or what? How do you use Globals? What are they good for?

      TIA

        • 1. Re: Globals - when, how, where?
          philmodjunk

          I understand they are fields that are independent of relationships or tables, and that they have to be on a layout for that layout to use them,

          Global fields do not have to be on a layout to use them. They are just like any other field in that regard.

          Global fields have several key properties that make them very, very useful. You've mentioned one: they are independent of any specific relationship or table. Thus a value in a global field can be accessed from any layout and from any record in your database. Many scripts exploit this feature. Say a user selects a key value in a drop down list set up on a global field. Since it's a global field, any script can access that user selected value no matter what layout and record is current.

          Here's another key feature: Data in a global field is accessible when your layout is in Find Mode. Thus, many developers set up search forms made entirely of global fields. A script can then enter find mode and use the data entered by the user into these global fields to construct complex find requests that the average user would find difficult to do in a manual find.

          Global fields can be used on the "one" side of a one to many relationship. This was more useful before FileMaker 11 introduced portal filtering, but there are still many cases where it is convenient to include a global field on the Parent or Single record side of a relationship where you want the user to be able to control what records are currently related to the parent record without having to conintually re-enter this value should the user move to different parent records. (These relationships are "one way", you can't refer to related records from the child table in this relationship like you can when you don't use a global field.)

          Values in global fields are specific to each user in multi-user environments. This one is hugely useful, but often trips up newbies when they first share their database over a network and find the hosted database doesn't function exactly the way it did for them in single user mode. Any changes made by a FileMaker client to the value in a global field are not seen by the other users. Any changes made to the value of a global field are not retained when the client closes the file. Thus, many different users can interact with the values in global fields, but their actions will not interfere with one another. Since client initiated changes don't "stick" you can load global fields with a "default" value as a consistent starting value for that global field.

          • 2. Re: Globals - when, how, where?
            basilisk2

            If you can only use them on the One side of a one to many relationship, what do you use instead of them in a many to one relationship?

            What kind of data are they commonly used to store? Key fields? A characteristic of the parent table that relates to a child table (but doesn't the relationship do this already?). Do you have any specific examples?

            • 3. Re: Globals - when, how, where?
              philmodjunk

              You can't go from many to one when you have a global field in the parent side of the relationship as that value doesn't identify any one specific record in the parent table.

              In many cases, we need temporary links based on user input that either don't rely on the current record in the parent table or that "filters" the relationship between the two tables at the data level. (Filtering a portal takes place on the display layer.)

              Say you have this relationship for an invoices portal:

              Invoices::InvoiceID = LineItems::InvoiceID

              If we modify the relationship to be:

              Invoices::InvoiceID = LineItems::InvoiceID and
              Invoices::Globalcategory = LineItems::Category

              we can format GlobalCategory with a value list and the user can select values in this field to see and work with different subsets of the total line items for that invoice.

              While I can also do that with a portal filter in FileMaker 11, I can't in older systems and sometimes we get smoother updates of aggregate calculations based on this relationship than you can get with a filtered portal.