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.

Use a global variable unless you have to use a global field or if security is an issue.

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

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!

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.

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 is no small advantage, me thinks.