Global Storage on a Calculation

[Rob P]

I was very excited when FM introduced global storage on calclations, oh, way back I think in FM7. However, I have yet to make it work.

How have you used global storage on a calculation successfully?

It seems that any time I've tried to use it, whatever value it has at startup is stuck there for the entire session and never changes regardless of the dependencies it may have. I found this particularly frustrating. What is the point of having a globally stored calc, if it never changed based on the dependencies. That puts you back to an UNstored calculation on every record to achieve something that was more dynamic--say a calculation that references a global that you could change. That's stupid, now I need 2 fields and I have a value for every record that's the same.

globalCalc.fp7.zip

[comment]

never changes regardless of the dependencies it may have.

I don't think that's an accurate statement. A global calculation is stored, and it recalculates when a referenced field in the same table is modified - not that different from a non-global stored calculation.

[d1132]

I got the same frustrating problem.

I want to use a caculation field for rational relation. It suck.

the caucualtion field can't be stored, hence the relation doesn't work....

This is a big problem for filemaker as a db system

[comment]

I answered in your thread - please do not double-post.

[Søren Dyhr]

Perhaps you should tell us about the task you wish the feature to perform, the use of globals as such isn't fully embraced as such and why pull it by condtional formatting that occur later in the evaluation cycle than the evaluation of calc'fields.

Somewhat same selectivity of when to calculate what and why could be done via this:

Case(Get(CurrentLayoutNumber) = X;mycalc) in an autoenter field with the update feature chosen.

--sd

[Rob P]

Hey Soren,

I can usually make out what you are saying but this time I got lost in your response.

Why use a global calc? Well, to be honest, at the moment I don't have a good example because I have had to work around them for so long that I just never use them any more. Hence the question, how do YOU use global calcs. I wanted to see how the developer community has utilized the feature. I figured it was just something I was missing.

I'm not quite sure what d1132 meant. I use globals to drive relationships all the time. Come to think of it. I've got an example for you.

Let's say that you're maintaining a daily to do list. When I log in, I have a global calc that resolves get ( currentday ) to drive a relationship of all tasks due today (or later if that's how you wanted it to set it up.

I don't believe this works.

[Søren Dyhr]

Let me suggest you think cartesian relation when you think you would need a global, just as starters ... isn't it so with all artforms. Mastering is knowing when to merely hint in a direction, than actually do it, and on the other side knowing a fair amount of the tricks of the trade - makes you know when to break fundamental rules.

Take a look at my template in this thread...

http://www.fmforums.com/forum/showpost.php?post/298125/

I'm for the time being abusing Ugos method all over the place, which isn't a guarantee that I'll continue to do so, I hope similar you are about to flock the dead horse with Globals, and eventually will get over it, in your pursuit for excellence.

--sd

[comment]

When I log in, I have a global calc that resolves get ( currentday ) to drive a relationship of all tasks due today (or later if that's how you wanted it to set it up.

I don't believe this works.

No, it doesn't, nor is it supposed to. Why not use an unstored calculation field instead?

[Rob P]

Well, see, that's just it. That IS the work around, that you have an unstored calc, but that becomes an unnecessary data field in every record when it should in fact act as a global. FM treats globals on a different level than data fields in that respect.

So what I'm trying to get at is, what is the point of global storage on a calc field? How can I, as the developer, leverage that potential?

[comment]

you have an unstored calc, but that becomes an unnecessary data field in every record

I'm afraid you are mistaken about that. There is no data in an unstored calculation field - only a formula that is evaluated when needed (and only when needed). This is not a workaround, that's how it needs to be.

what is the point of global storage on a calc field?

Obviously not this one, but I believe you will find some good uses for it, if you search the forums.

[Fenton]

I agree, that it is a little confusing. One tends to think that a calculation with global storage will behave exactly the same as a field with global storage. And it does, mostly. But the calculation with global storage is very "sticky." That is, if you change one of the values the calculation is referring to, the calculation does not appear to change for quite a while, especially on a networked file, where it seems to wait until FileMaker Server flushes its cache to disk before the change is visible.

I find them useful to store such things as solution-wide graphics, and the business's logo, address, etc.. But even there you need some patience, if you make a change.

The calculation would be pointing at a regular field. I use them instead of having to set a bunch of globals at startup.

[Rob P]

That's pretty much what I'm seeing. It's sticky and you're not quite sure when it will change.

So, the conclusion is, if you're looking for lively updates, go with the less sticky unstored calc. But if this is something that is supposed to be relatively static, global stored calc is fine.