From Dwayne Wright PMP
Certified FileMaker Developer
Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).
A READER ASKS
I am hoping you can help with my understanding of use of a field defined as “global” and how I am using them in my scripts. What I have done in all my scripts is to use a number of fields defined as “Global” and use these to pass values from one script to another.
e.g. In Script A (I set the global field with a value), then I call Script B from within Script A. The first thing I do in Script B is to read this Global Field and set a variable using the value I have just set in Script A and then use that variable in Script B.
Are you able to confirm if this is correct or if it will cause issues.
To help illustrate my points, I created a series of training videos and here are the links. Try right clicking the links so that you can bring up the movies in a new window.
What a great question! The good news is that this technique is widely used and a reliable way to pass information between scripts. In fact, it was the only option available to FileMaker developers for many years. Ah, there is the rub isn’t it. Although this technique works, I don’t think any career FileMaker developer uses this technique any longer.
Most career FileMaker developers will use a script parameter, a script variable or an exit script result to pass information from one script to the next. The script parameter and exit script result methods can be used between files. As of FileMaker 11, memory variables cannot be used to pass data from one file to the next (at least, that I'm aware of).
There are few real problems with the global method you are utilizing. You may run into issues if you are working with date information and the global field is formatted as a number type. This type of data / field type mismatch doesn’t always present a problem but it can become one. If you accidentally delete the field, that will break your script. The scripts are less portable from one table to the next, because you have to account for the global field. Deleting the table occurrence from the relationship graph that is the reference for the global field can break your script. All of these are pretty rare occurrences but they can happen over time.
Script parameters, script results and script variables don’t have these same problems and don’t introduce any really new potential hiccups. They have other advantages as well and this is why they are embraced by professional developers. They also are not that hard to master, so you could start using them without learning something complex.
© 2012 - Dwayne Wright - dwaynewright.com
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.