Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
The Claris Museum: The Vault of FileMaker Antiquities at Claris Engage 2025! ×

This topic is 5234 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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.

Posted

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

Posted

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!

Posted

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.

Posted

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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.