I just started working on an existing solution that uses what I consider to be a large number of global variables - approximately 75+ of them. They are mostly all defined during the startup process. They contain a range of things from static values pulled from a Settings table, to more dynamic values. The system is hosted on FM Server and accessed remotely via FM client, Web Direct, and FM Go with the majority using Go.
Is this number a potential concern from a memory standpoint? Does the fact that most users are on FMGo (iPads) influence this? Thoughts on security as some of them contain sensitive information? The FM app users can’t get to the tools menu to enable the data viewer, but I haven’t checked this thoroughly yet.
The system has several issues that cause it to be slow over the WAN. I don’t recall hearing about a lot of global variables being a potential speed factor, but glad to be corrected on this.
The explanation for this is could be unstored calculated fields. On a LAN it may be acceptable, but on WAN it would worse. Fields can be unstored for two reasons:
One has not set the property to stored
In some circumstances calculations can't be stored
Regarding global variables I agree that having much of them can be a pain to manage: for example just misspell the name and voilĂ you created a new variable . You may instead use global fields whose values are per user.
I manage a database that uses global variables for language localisation. There is more than 75 variables and it doesn't seem to cause problems for the users. It's a nightmare in the data viewer but that's a different story.
Using globals for sensitive information is definitely a bad thing. Change them to fields (possibly global fields) where they can be properly secured.
WAN performance can be many things, and if it's a system built for the LAN, often they all occur at once.
Maybe use global fields as formulas containing just the value. But of course do not use these globals in other formulas because they cannot be stored (as [planteg] stated.
Thanks for the information. I dug into the system some more and it is actually using 190 global variables! We will likely move the sensitive data ones to global fields as suggested (was thinking this already).
Using the data viewer is a pain for sure with this many.
To kind of clarify my original question, I was looking to see if anyone had experienced database issues that were found to be linked to a high number of global variables.
Seems like this isn’t an issue. Feedback from other areas is the same.
Having a solution (developed before native JSON support) with hundreds of generic global variables including mechanics for GC (garbage collection after usage) I can tell that there was no slow down if enough cache memory was assigned in FM client. Officially this has not been ever confirmed just an observation that on Windows with roaming user profiles it could have been one issue of a serious slowdown.
. You may instead use global fields whose values are per user.