Variables are only created in scripts. There is a script step called "Set Variable" and you can set the variable preceded by $ or $$ and its value. If there is single $ before the variable (e.g., $Variable ), then that variable only exists during the execution of that script and it goes away when the script ends. If the variable is a global variable with $$ before the variable (e.g., $$Variable ), then the variable remains in memory until you quit the FileMaker program. The global variable is useful if you want to show the variable in a text field in a layout. It is also good for saving the variable in memory so that other scripts can make use of them. For example, in your startup script you may set some preferences such as zoom or size of screen and save that in a global variable. Then when you open or go to new layouts, you can have other scripts resize the window or its zoom according to the global variable preference set at the startup script.
One of the biggest advantages of a variable is that it is stored in RAM and not your hard drive, making it much faster than reading and writing to a global field. Also, some functions are very slow in FileMaker. Many of the Get functions are some of the slowest functions in FileMaker. If you have a long script that uses a Get function a whole lot, you can speed it up by setting that Get function to a variable at the beginning of the script and calling the variable every time you need the value instead of performing the Get function again.
I use variables a lot to create arrays. Frequently I want a bunch of information from some records in a layout and want to go over to another layout and place that information there. You can always do a bunch of go to the new layout, return to the original layout, get more info, got back to the new layout, etc. But layout switching is VERY slow in FileMaker because it changes context. Instead I usually write an arran of all the information I want to bring to the new layout, then make a single switch to the new layout and pull all of the information from the array instead of jumping back and forth or working through a relationship. It makes FileMaker perform faster.
If there is any chance you are going to Devcon, there will be quite a number of sessions going over cool things you can do with arrays.
But, no, you don't have to use variables. And sometimes a Global field is a better way to go. But if you're trying to optimize things for speed, try to use variables as much as you can.
There is a help page for the Set Variable script step: http://www.filemaker.com/12help/html/scripts_ref1.36.15.html#1044136
and for Using Variables:
And yes, I'm going to DEVCON.
I guess I just need to muddle through it so I can get the hang of it. Once I've done it once or twice I'm sure I'll get it.
(That page did help )
You might try posting a simple file that demonstrates how you're trying to use variables and where you're runnng into problems.
I haven't tried. I've just used Globals.
I'll get it. I just learned tonight that a variable isn't a field at all; only a script step. Sounds like its 100% scripting.
Sent from my iPad
Actually you can also create Globals variables outside a script in either a Tooltip or Script parameter...
Let ( [
LETVAR = "EFG" ; // This "Let" variablle will only exist within the Let Function.
$LOC = "ABC" ; // This "Local" variable will only exist withing the scope of the entire calculation
$$GVAR1 = "1234" // This "Global" variable will exist and sustain at the file level.
] ; "" )
Taylor - a really helpful explanation. Thanks, from one who uses variables a lot, but should use arrays more!
A variable is created as a script step. It can be used in many ways. For instance if you want a label for a button to change based on what the script does. Have the script set the variable using a Global $$ variable and have the button label be a merge variable. As an example I have a script that shows a list of items and toggles from all records to current inventory. The button label toggles from "Show all" to "Show Current". The script looks at the global variable and does a find or show all based on current value and has a set variable set in each branch of the if.
Another use can be in creating new records in a loop. Have the fields setup as auto-enter fields with the formula being the variable for the field. Have the script set the variables then do the new record command. A new record will be created and the fields will have the value from the variables.
I have felt your pain cowens1. As a newbie, I looked through the Starter Solutions, and tried to "find" these variables, I was confused. It took some head scratching until the light went on that a variable wasnt a field. Just like riding a bike, in a short time you wont even give it a second thought.
1 of 1 people found this helpful
Not quite true.
A variable is a defined value created in memory, rather than defined in the database schema. So you're correct in that it's not a field. But they are not 100% created via script. As pointed out by wsvp above, they can also be defined inside a calculation via the Let ( ) function. Since they're created in memory, they're:
1) Very fast.
2) Not saved anywhere inside the database.
3) Created entirely at the user's workstation.
4) Not seen by any other user.
5) Evaluated when needed and preserved for the duration / scope as defined (local to the Let function, calculation / script, or session, or until destroyed).
6) Not part of the dependency tree (i.e., changing a variable's value will not cause any calculation dependent on it to update).
It is a little confusing just because there are different kinds of variables, as WSVP said, they can be defined in a calculation, using the LET function… and those don't need to start with $ or $$.
Then, there is the Set Variable script step.
I think we all used to use Global Fields, because variables weren't always there. So, it's very believable!
Now, I use variables pretty much the same way for many things. The advantage to me is that you can just create them on the fly when you are scripting. You don't have to go back to your Manage Database window to create more Global Fields. Basically the Set Variable script step replaces where I used to use Set Field with a Global Field. If I only need it for that one script, I use a $variable. If I'll need it to exist beyone that, I'll use a $$variable. But whenever possible, I like to "clear" the $$variables when I'm done with them. You do this by adding a script step of Set Variable [ $$variable ; "" ]. Setting it to "" makes it go away. That way, it's not taking up any memory anymore and it's not cluttering up my Data Viewer. Of course, there are some that I alway need around, but I try to keep things tidy when I can.
And there are some cases where a Global field is still necessary, like creating some TOs, filtered portals, etc.
Learning every day!
This is almost correct. Local variables (one "$" prefix) persist beyond the calculation that set them. If the variable is set in a calculation within a script, the variable will persist for the rest of the script. If the variable is set in a conditional formatting calculation, the variable will persist at least for the rest of the layout rendering, which some folks use to set local merge variables (watch your object stacking order!).
1 of 1 people found this helpful
In the olden days, the before-time, scripts only had global fields to maintain temporary data and pass information from one script to the next. Variables are one FileMaker feature that reduce the need to use global fields (and therefor clutter the database schema with non-data). Script parameters and results, introduced earlier, have done just as much. When a script needs information it can't derive from context (data in the current layout or record or Get or design functions), trying to pass that information to the script as a parameter (or back as a result) should be your first instinct before you consider using a global variable. This helps minimize certain kinds of problems where different parts of a solution compete for control of the same global.