owangolama Posted September 22, 2010 Posted September 22, 2010 How does one go about deciding when to use a global field as opposed to a global variable? Sorry... not sure where to ask this one.
David Jondreau Posted September 22, 2010 Posted September 22, 2010 Use a global variable unless you have to use a global field or if security is an issue.
Søren Dyhr Posted September 22, 2010 Posted September 22, 2010 The urge to globalize in this context, could be evidence of a poorly structured solution ... the problem is in the maintenance of the value it holds due to the scope! --sd
owangolama Posted September 22, 2010 Author Posted September 22, 2010 Thanks for both answers! I'm afraid that I don't quite understand the second one. Perhaps you could elaborate? I find that I have a lot of instances where a global variable could be used instead of a global field. If I'm simply tracking something's value and I don't, for instance, need to use it in a relationship or display it to the user. Debugging these variables, however, seems tougher. For instance, if you mistype a field name, FM will tell you. If you mistype a variable, it simply creates a new variable. If I were perfect, then of course this wouldn't happen, but it does, and can occasionally cost a lot of time. Similarly, if I'm trying to get rid of a global field, simply attempting to delete it from the table will tell me if it's still in use somewhere. I don't believe there is a similar solution for variables. Obviously, these are human shortcomings imposed on a programming environment, but are nonetheless relevant. In general I have zero security concerns. I'm concerned only with speed and ease of programming/debugging. Any further feedback would be greatly appreciated!
TheTominator Posted September 22, 2010 Posted September 22, 2010 How does one go about deciding when to use a global field as opposed to a global variable? It usually boils down to finding the right one for your situation. Global Fields ---------- Stored in the file and thus can be persistent between (single-user ) sessions Has a distinct type (Text, Number, Date, etc.) Can be a Container Compatible with clients using FM 7. Can be exported/imported Can be used in relationships Global script variables ---------- Can be spontaneously created without cluttering the list of fields Can be assigned to in any calculation via a Let() statement.
Vaughan Posted September 22, 2010 Posted September 22, 2010 Stored in the file and thus can be persistent between (single-user) sessions Don't tell people that. They'll build something that relies on the behaviour then wonder why it breaks when the file is loaded onto FMS and have to completely re-engineer it. One advantage of global fields not yet mentioned is that they are useful for transferring data between files, and they can be accessed without a direct relationship in the same file.
owangolama Posted September 22, 2010 Author Posted September 22, 2010 This is no small advantage, me thinks.
Recommended Posts
This topic is 5234 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now