Questions about Global table

Questions
1

Years ago I read some forum post talking about the advantages of a Global table and at the time it seemed like a good idea. I have been using them in a lot of my databases sense then and for the most part they have worked well.

Questions:
Are Global tables a good idea? I am just curious, I have been Googling about them and was a little surprised by how little I found people talking about them. Would love to hear others peoples thoughts on them.

While researching global tables I found another post pointing out that global fields in a table without any records can still be set and accessed. This has me thinking about setting up my Global table this way. Maybe this is how everyone that uses a global table?

I can see a couple advantages to this setup, like multiple users would never have an issue of there search bar or export settings changed be another user. I would not need to make sure a empty clone has a Global record before syncing.

Any input would be welcome

2

A global table is, in my opinion, a good idea. It helps reduce clutter in tables. Same with code.

I also find it useful to have a record because I sometime add local fields to a global table. This allows me to set initial values in local fields that are then transferred to the global fields during an initialization routine. Unlike global fields, local fields can be modified remotely.

That said, not all global fields can reside in the global table. Some global fields must reside in tables from which relationships using them need to exist.

Hope that makes sense and hope this helps.

2 Likes
3

Thanks for the reply and I love feedback of any kind. It helps me get confidence which at times I am lacking :slight_smile:

Not sure I follow on this section can you elaborate some more please.

I have another table we use for storing organization preferences that in a lot of ways acts as a global table but one that for sure needs a record. We could use the same table but I find separating them helpful.

4

If you want a relationship from table A and B that uses a global field, that global field must also be in table A or B.

1 Like
5

A GLOBAL table is immensely useful in keeping clutter down in your relationships. Global fields are accessible anyplace in the solution.

However, IF you are using the global for say, a MATCH condition in a relationship, that global must exist in the parent table so as to be available to the relationship.

Naming conventions are really useful in this (and all through FM). For my purposes (and preference) all global fields in the global table start with a "g_: then "fieldname". That way, where ever they appear in a solution, I know where to find them.
Globals used as constants start with "gk_"; if in a data table, "zgk_"
Globals used as a relationship match start with "zgm_"

..... and so on. The preface starting with z in a data table, takes the fields out of the alpha sorted list of data, and places them at the end. Global "zg....." tells me the field are in a data table, NOT a globals table.

And of note: Global fields (and $$Global variables) are persistent only for the duration of a given user session. They do not persist outside of a login.... with one exception. Globals set in a file upon upload to a server, default to those global values with the start of each user session, which has its' pros and cons (mostly cons).

There are also a bunch of rules on the use of globals, best articulated by the esteemed FileMaker expert, Dr. Ray Cologon, shown in the following bullet points. It is worthwhile to copy and retain these points, as they are invaluable learnings.........

  1. A global calc will update automatically if it references a global field that is located in the same table and that field is edited by the current user.

  2. A global calc will update automatically if it references a regular field that is located in the same table (and referenced directly) when that field is edited on any record by the current user. In this instance, the value of the global calc will depend on the value of the referenced field in the record in which that field has most recently been edited. When the global calc references multiple regular fields, its value will depend on the values in the instances of those fields located on the particular record where the most recently edited (by the current user) of any of those fields resides.

  3. A global calc will NOT update if it references a global field that is located in another table, if that field is edited by the current user.

  4. A global calc will NOT update if it references a global field (in the same table and referenced directly, or in another table) that is edited by different user (users see their own separate global values...).

  5. A global calc will NOT update automatically if it references a regular field that is located in the same table (and referenced directly) when that field is edited on any record by another user.

  6. A global calc will NOT update automatically if it references a regular field that is located in a related table (even if a self-relation) if that field is edited on any record by the current user or by another user.

  7. If a global calc references one or more related fields (as per 3 and 6 above) and ALSO directly references a local field, either global or regular, the value of the global calc will depend on the related values which are current (for the current user) at the time when the local (to the table in which the global calc resides) value/s are edited.

  8. The value of a global calc when a solution is opened remotely will be the value that it had on the host when last closed (sound familiar?!).

  9. The values of global calcs in a hosted solution can be 'tickled' at login by changing a local field which they reference. Eg if there are several dozen global calcs with formulae constructed along the lines of:

If(not IsEmpty(GlobalsTable::RegularTriggerField); RelatedTable::dataField)

then they will all update to reflect the current (related) values at start-up if the start-up script includes the command:

Set Field [GlobalsTable::RegularTriggerField; "1"]

  1. Changes made to referenced regular fields on another workstation will not appear in global calc results until a refresh event (eg as per 9 above) has occurred on the current workstation - eg the next time the start-up script runs. If there is no triggering mechanism (as per point 9) then the changes will not appear at all until the solution is taken offline, updated in a client session, closed and reopened on the server, as is the case with non-calc globals.

As usual, you can take information like this from Dr. Ray to the bank.

2 Likes