I have a utility table where I store icons and preferences in non-global fields. For each of these non-global fields there is a global field. I use the globals so that I can use the data in the fields from any table or file without creating a relationship to the utility table.

Until recently, each of the global fields was set up as an Auto-enter calc and the calculation was just the non-global field that the global was associated with. I would populate the globals by putting each of the non-global fields on a layout and running a script that looped through each field setting it to itself. That works just fine.

I thought of a more efficient way of populating the globals. I created a global field in the table called "g_Trigger". I then changed the auto-enter calc in the globals to be something like this:

Evaluate("field1"; g_Trigger)

With that in place, I no longer need to run a looping script. I just go to the layout set the g_Trigger field and all the globals populate.

There seems to be a gotcha though. This doesn't work with anything but the first repetition in repeating fields. It worked fine the previous way, because I was looping through the fields which went to each repetition and set it to itself.

Before I go back to the looping script method, I thought I would throw this out to you guys to see what you can come up with.

Why not make the second field a global calculation? Then you won't need a third field.

Why not make the second field a global calculation? Then you won't need a third field.

Well, global calculations seem buggy to me. I admit, it could be just a lack of understanding of global storage for calculations. I just messed around with it since you suggested it. I found that the calculation doesn't recalculate until you exit FileMaker and re-open the database. Really weird. My confidence in using global storage for calculations isn't real high.

Also, and I may be wrong in this logic, but if it is a global calculation, my thought is that it would need to recalculate every time the field appears on a layout like an unstored calculation. So, there may be some performance issues.

I actually got it to work by using a suggestion by one of my BAFDA cohorts. The suggestion was to use a lookup instead of auto-enter calc for my repeating fields. The unfortunate thing is that the lookup requires a relationship which I really didn't want cluttering up my Relationship Diagram, but it works.

A global calculation is stored. Therefore it would NOT "need to recalculate every time the field appears on a layout like an unstored calculation". It will recalculate instantly whenever a referenced field IN THE SAME TABLE is modified.

A global calculation is stored. Therefore it would NOT "need to recalculate every time the field appears on a layout like an unstored calculation". It will recalculate instantly whenever a referenced field IN THE SAME TABLE is modified.

Thanks Comment. I am going to try changing everything to global calculations and see how it does. What I find odd though is that the repeating field problem exists when using the auto-enter calculation, but doesn't exist when using the same calculation in the global calculation.

I have another question for you Comment to sort of clear things up in my head, and this question isn't restricted to globals, when would you opt to use an auto-enter calculation instead of calculation and vice versa? Are there performance hits associated with using a calculation field instead of auto-enter calcs?

Please let us all know how it goes. I got this idea from another forum, and I think it's a brilliant solution, but I don't have a network to test it with.

The auto-enter problem seems like a bug to me. Haven't found a workaround for it yet.

I don't know if I can give a precisely formulated answer to your question: it depends on so many factors. I think I can say that if anything needs to be calculated, I will use a calculation field for it - unless I have a reason not to. Among possible reasons:

- user needs to be able to override the result;

- result needs to be calculated now and frozen (these two are essentially lookups);

- result references a global/related field, but needs to be stored (almost never required, and always problematic, as it will not update).

I don't see why there should be any performance difference between a stored calc and a auto-enter. Unstored calcs, if placed on the layout, or otherwise referenced, can slow things down, so that's worth watching, but the trade-off is file size.

Thanks Comment. I will let you know if I have any trouble with the Global Calcs.

Also, those were the situations that I had in mind for using an auto-enter calc as well. In retrospect, I believe I got a little carried away with auto-enter calcs in FileMaker 7/8. The perception I had was that even stored calculation fields are somehow in a state of perpetual calculation and that auto-enter calcs only calculated at a single point in time until something referenced in the calc changed.

This clears that fuzzy area in my FileMaker knowledge. I appreciate it.

As a followup to my testing with Global Calcs...

I have gone back to the auto-enter with a trigger field approach except with repeating fields in which case I am using a Lookup. The lookup populates all repetitions.

Using Global Calculations was not reliable. I am not clear on exactly how they update. I had instances when the global field didn't match the contents of the field it referenced.

I don't have a lot of time to spend trying to figure out what the problem may be at this point, so I am going back to a way that I have confidence in. There must be a good use for global calculations out there, just not the use I was trying them in.