I noticed today that if I create a global container field on FMS, that container field does not retain files I put in it after closing the app and restarting it (either from FMP or Web Direct).
Global containers seem to work fine from standalone FMP, however.
Is this FMS (latest version) global container field issue documented with workarounds?
Thanks,
It has always been this way with global fields. Per FileMaker's documentation:
The client’s initial global field values are those that were in use when the file was last closed by FileMaker Pro on a local computer (not via FileMaker Network sharing). Any change a client makes to these initial values persists only for the duration of the client’s session. If a client closes and then reopens a file, all global fields are reset to their initial values. To change these initial values without closing the file on the host and opening it locally with FileMaker Pro, set the initial values of global fields in a startup script.
6 Likes
Thanks. This FMS, but not FMP local, behavior surprised me.
Appreciate your help.
If you set a global container field locally, then upload to the server, the server will retain the global. That is the exception to the rules governing globals. The esteemed Dr Ray Cologon, wrote this piece years ago, explaining globals.......
-
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.
-
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.
-
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.
-
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...).
-
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.
-
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.
-
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.
-
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?!).
-
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"]
- 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.
4 Likes
Thank you! Excellent.
The general overarching concept: globals persist FOR THE CURRENT SESSION only.
The implications are significant. Logging out and back in, and all existing globals are gone.
Running a PSoS or server scheduled script is run by a user FMSE - not you - so that "user" has no insights into your globals - fields of $$variables.
The other side of the coin - globals are yours and yours only. What gets entered in globals are NOT available to anyone else.
Common practice is to set up a preferences table, either with on record and a field for each "to become" globals, or one record per "to become' globals, and a start up script that writes those static preferences for globals that are accessible all over the program. Since the advent of $$Variables, it is common for many of what used to be global fields, to now be global variables (unless of course, you need that data for a relationship, then a global field is necessary).
1 Like
I try above all to avoid global anything. Sometimes in FileMaker, globals are still useful or necessary.
I appreciate your reply. 
Re: "Is this … documented"
Certainly is. See FM Help here:
https://help.claris.com/en/pro-help/content/global-fields.html?Highlight=global
… in particular: "The client’s initial global field values are those that were in use when the file was last closed by FileMaker Pro on a local computer"
What I see is that I can save a file into a global container field on FMS, but the next time I open that FMP app, the container is empty.
Exactly! That is because the last time the file was closed unhosted the field was empty. That is intended and expected behaviour.
The use for this is to have a file you need to work on and then dispose. For example you get a picture saved as encode64, you decode it show it and then it goes ! Since each user has it's own global field, no one interfere with others.
OK, thanks.
Where I get "stung" by this is when I want a "Settings" table (almost always) that holds company name, address, logo, bank wire transfer info, etc. that will show on invoices, quotes, etc. If I don't preload all of the details prior to uploading to FMS all changes are lost. The fix (for me) is to have "Settings" TOs related to each appropriate table such as Invoices, Payments, Consignments, and so fourth. More clutter in the relationship graph, but needed if the client is to be able to update the info themselves.
Why don’t you have both?
Have a settings table, typically a single record, and a globals table, also a single record. Your startup script can push the images in your settings table across to your global table.
2 Likes
I agree, Malcom. I do have both in nearly every solution. They’re two of the first tables I create, typically.
I don’t care for the startup script to be (solely) responsible for pushing the Settings content because clients typically like to make a change (new bank, change default email signature, etc.) and see the results immediately. Of course a “Save Changes” script (or Auto-enter calc) can push that content to Globals as well (although I don’t mix Settings and Globals table content, but then need to have global storage fields in Settings to push the changes into). I do this in larger projects or if the settings are needed in a greater number of places. It’s obviously much more scalable.
It just depends on which is easier to maintain. (And maybe my mood. 
) If there is a lot of output (reports, documents, invoices, receipts, etc.) I definitely prefer to script setting data into global storage fields; if it only affects a couple tables I can live with the additional TO.
That said, it’s definitely cleaner (in the ERD) to keep system TOs organized and not scattered around.
(My first reply above was a bit half-baked, as it related to a recent small project that just happened to come to mind… and I was interrupted while composing the reply. I should’ve returned to clarify. My bad. Thanks for your reply.)