FileMaker Memory Variables Explored

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

A Memory Variable is a collective name often given to local or global variables that can set via scripting (Set Variable Script Step) or via a calculation (Let Function). I realized that a lot of what I’ve written on the topic is fragmented across many posts on many different blogs. So I thought I’d exercise some organization muscles and consolidate much of this information into a single post.

A local variable is defined by adding a single dollar sign in its name such as $InvoiceNumber, $ClientID or $Counter. A local variable will store it’s information within the script / calculation while that script / calculation is running. After it is finished in it’s execution, the defined local variable will have no value. An advantage of this is like a disposable lighter. When you are done, you throw it away because you never intend to refill it.

A global variable is defined by adding a two dollar sign characters in it’s name such as $$InvoiceRange, $$Array or $$UserPrefs. A global variable will store it’s information within the entire file while the file is open. This way it can be used across scripts or even in-between times that scripts are called upon.

Variables are useful in simplifying complex calculations, passing information from one process to another and opening doors to innovation within FileMaker design. I have seen mixed interpretations of what a declared variable means. I had it in mind that declaring a variable was the process of creating it. After doing some research, I found most resources used the term as the variable in action (particularly when talking about troubleshooting a variable related problem).

So for the sake of conforming to a majority standard, I’m going to say that the term of a declared variable pertains to the use of an existing variable within a calculation or script.

When you create a variable, you give it a name. Just like when you create a field, you give that field a name. When you reference a field in a calculation, if that field name doesn’t exits, FileMaker tells you about it immediately. That is not true for variables when you use a variable in a script or calculation. Without the immediate feedback that a declared variable does not exist, the developer can introduce bugs within the FileMaker solution that are not easily tracked down.

Most variables in calculations are created, used and discarded within the same calculation. So depending on how intense a calculation is written, the developer can quickly see a typo in a declared variable.

Global variables are created and used within the same FileMaker file but are not discarded until the users session ends. Depending on the organization and documentation of the developer, the use of a global variable can be dependent upon proper activation and declaration. If a global variable with the same name is created in multiple areas of a FileMaker solution, it could lead to problems on how they are used. The same is true if the global variable is set to different values in different areas of the FileMaker solution. For this reason, many developer shy away from using global variables.

Now there is a movement afoot by some of the larger brained mammals in the FileMaker developer community. This involves the blending of variables, custom functions, external functions (via plug-ins), complex web viewer techniques and a junk yard full of other power coding techniques. The results can be impressive and make for great theater in presentations such as the annual FileMaker Developer Conference.

I know that it sounds like I’m dumping on the idea and that is not my intent. I am just introducing a little theater of my own on the subject. By all means, I’m all for pushing the envelope and enjoy standing with flabbergasted awe at some of the results these talented developers produce. I’m just saying that there is a risk in using these development techniques in production systems. This is a large step in entering the big boy arena and proper documentation and testing should be done. If you have ever seen a relationship graph from someone that induces a bitter beer face upon you, can you imagine how ... potentially ... out of control some of this higher level coding could get? I’m just saying ... you know ... the whole “with great power comes great responsibility" thing?

More info about the author and FileMaker in general, contact me at

© 2008 - Dwayne Wright -

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.