Need advice on globals

[K1200]

In building a runtime solution, I'd like to have certain "overhead" items on hand for displaying on various layouts. For example:

, which I would normally enter prior binding the runtime, but which I could change on a Master Parameters Screen after distribution, if ever needed.

, which is stored in a calculated field using the Get(FilePath) function, also for display on certain screens.

, which is a unique product/build identifier that I type in prior to binding.

I would like to have these and other "overhead" items in a Master Information Table, separate from all user-related tables. I've determined that, since they're in an unrelated table, they have to be global fields to be displayed on other layouts. (just why, I don't understand). But in reading about global fields, they seem more appropriate for "on the fly" information -- and possibly trickier to use for long-term parameters.

So my questions are (1) what's a good approach for my 10 or 12 overhead fields? and (2) when are global calculated fields (e.g., Get(FilePath)) actually calculated?

Thanks

[Razumovsky]

Hi-

Since FM7, the need for globals hasd been vastly reduced, if not eliminated. I am still trying to ween myself off of the habit...

Try creating a 'preferences' table that contains all of your overhead fields as non globals. Then create an all to all (x) relationship into your graph (I use the uniqueID fields as the key fields).

You will need one and only one record in this table.

In the case you described, globals would probably work as well, but could limit you in certain ways, especially if you want to expand from runtime to a multi user environment.

hth

-Raz

[Fenton]

There is also a new global storage possible for calculation fields. What you can do is to put your data into regular fields, as Razumovsky said, then create a "mirror" calculation field, equal to the regular field, but set its storage to global.

The advantage is that it requires no Cartesian (X) relationship to access those values, since globals are accessible without a relationship. Yes, it requires an extra field for regular values. But it saves mucho lines on the graph.

The global storage of calcs has one gotcha. Which is that "status" Get() functions do not reevaluate if set to global storage (at least I couldn't get them to). So these still need to be local fields in the tables.

You could also create a single "trigger" field, a global number field, and include it in the calcs. Then set it to 1 with an opening script. That would trigger the global calcs for that "session."

I haven't used this much yet. So if anyone knows any more, let us know.

[Razumovsky]

Interesting point Fenton,

I havent explored the global storage function much yet either, but have some reservations. I would think that if you ever wanted to expand the solution to allow user-specific 'overhead' values, you would have to abandon the global storage calc method and restructure your relational graph (happened to me on first FM7 DB...). With thoughtful consideration, you can get away with very few, often even one, relationship to a central hub. Dissecting the FM BusinessTracker accounts module was very educational for me in this regard.

-Raz