I remember long ago, when Variables came out, some developers made serous tests of the "variable vs. global". Yes, variables seemed to be a little faster, most of the time. But really, they were pretty close. It required thousands of records to see a difference. I think a "global" field is not really the same as the regular fields in the records. For one thing, you can enter and set a global field if there are no records yet. I believe that FileMaker only sets it ones, no matter how many records.
My approach now is more like: Use a local Variable if possible, otherwise check whether you have a good reason for a global field; if not, maybe use a global Variable. But "good reason" to use a global fields, I'd mean that I need to use for something else (other than just the script), such as for a relationship, or to be enterable on a layout (maybe with a Value List), etc..
Some people use global Variables a lot more than I do. They way set a bunch of them with values on startup, etc., to use for lots of things (I already said that, but I don't really know the specifics). I suppose it might save them from having multiple global fields. But since global fields can often work from a dedicated "Globals" table (with only 1 record), I'd just use that (the old way).
In your second question, re: How do you see all this? I say, FileMaker Pro Advanced, Tools, Data Viewer. It will show you all the variables and fields running during a script (if you also have Script Debugger on); it sorts them by name, so you'll the variables (global) $$, then (script's) $, are visible (in that order). It will also show (only) the global Variables if there's no script running. So that is one way to know whether one of them is still on.
- You can not build relationships using script variables (You can do that with globals)
- using script variables, You don't have to 'touch' field definitions ('manage database'). A big plus in a multi-user environment
- using script variables, You can define them in a script when needed (also using 'let' function, etc)
- script variables are text. You have to take care by Yourself in specific circumstances
- script variables 'live' in a file, You have to pass them using script parameters (etc). Globals are accessible via relationship
- using script variables, there is absolutely no syntax check. Typing mistake, no result/wrong result..
as said, You can have the data viewer to display the content of a script variable, further on, You can have them displayed in a layout (~placeholder) - You have to update window to get actual values
Both thanks for your reply, effort and time,
This will help me. I was always struggling with this matter, because in many cases you can use variables as well as global fields.
And I know I have to use global fields if a calculation is used, like "< then" or similar cases. And indeed, there is no syntax check,
Thank you both.
Another benefit to using variables is that you can construct scripts and layout elements that are "portable" as they won't have Table::Field references in them that would then need to be updated if you were to move that script or group of layout objects into a new file.
That's the main reason why I made extensive use of global variables in my recently release Date Picker for FileMaker GO. Because it's all done with global variables, I can import a few simple scripts, then copy and paste the date picker into a new file. The only field specific detail is a single field reference used as a script parameter in the button or script trigger that opens this date picker.
The "portable" issue is an important one. I have a lot of "find criteria" in some scripts. It happens quit a lot that I need the same "find criteria" in another table occurrence. I have to change the field references every time. With variables I don't have to do that anymore. And indeed, it will be easier to move scripts and lay outs,
Thanks for your extra input,
You are right, you mean portable "between files. And that is a very valid and good reason. But until now I did not move a lot between files. But I was just busy to have a look at the Date Picker.