# Too many Global Variables?

**URL:** https://the.fmsoup.org/t/too-many-global-variables/2827
**Category:** Questions
**Tags:** security, performance, filemaker
**Created:** [March 29, 2022, 3:01am UTC](https://the.fmsoup.org/t/too-many-global-variables/2827 "2022-03-29T03:01:55Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![bowdendata](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@bowdendata](https://the.fmsoup.org/u/bowdendata)
#### Post date: [March 29, 2022, 3:01am UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/1 "2022-03-29T03:01:55Z")

</div>

Hi All,

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.

Thanks,  
Doug

---

<div class="post-metadata">

### Author: ![planteg](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/planteg/32/627_2.png) [@planteg](https://the.fmsoup.org/u/planteg)
#### Post date: [March 29, 2022, 3:53am UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/2 "2022-03-29T03:53:06Z")

</div>

> [@bowdendata](#):
>
> The system has several issues that cause it to be slow over the WAN

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.

---

<div class="post-metadata">

### Author: ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)
#### Post date: [March 29, 2022, 6:21am UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/3 "2022-03-29T06:21:54Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![LVZ](https://avatars.discourse-cdn.com/v4/letter/l/5f9b8f/32.png) [@LVZ](https://the.fmsoup.org/u/LVZ)
#### Post date: [March 30, 2022, 8:29pm UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/4 "2022-03-30T20:29:47Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![bowdendata](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@bowdendata](https://the.fmsoup.org/u/bowdendata)
#### Post date: [March 30, 2022, 10:29pm UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/5 "2022-03-30T22:29:48Z")

</div>

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.

Thanks all — Doug

---

<div class="post-metadata">

### Author: ![FileKraft](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/filekraft/32/1183_2.png) [@FileKraft](https://the.fmsoup.org/u/FileKraft)
#### Post date: [April 4, 2022, 3:00pm UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/6 "2022-04-04T15:00:53Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![bowdendata](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@bowdendata](https://the.fmsoup.org/u/bowdendata)
#### Post date: [April 4, 2022, 5:54pm UTC](https://the.fmsoup.org/t/too-many-global-variables/2827/7 "2022-04-04T17:54:54Z")

</div>

Thanks for the comments.

Doug
