Global Calcs

[Genx]

Can someone please explain how these work and what triggers their recalculation.. and why you would use them because I for the life of me can't work it out.

[Søren Dyhr]

Wouldn't it be more relevant to know, what you wish to throw them after? I shy away form everything only slightly global ... or rather suspect myself for making a relational blunder if they're required!

--sd

[Genx]

Well I don't want to throw them after anything, they are just there and I never use them... mainly because a) I don't get how they work, What you would actually use them for, c) how they differ from potentially a global combined with an unstored calc, d) ... they're there and i've never used one, I just want to know if i'm potentially missing out on something.

[comment]

See if these provide an answer:

 

[bcooney]

Would you mind explaining to me why a global calc=1, doesn't equal 1 until a new record is created? It's this behavior that has me avoiding global calcs for pref values.

[comment]

I'm not sure that's an accurate description - perhaps you mean why a global calc isn't evaluated until there is A record in the table?

[Genx]

Right, so they don't recalculate when they're on a layout... but i assume they will recalculate if some referenced variable or field within them changes, but what is it that triggers the initial calculation ?

[comment]

they don't recalculate when they're on a layout...

They recalculate regardless of whether they're on a layout or not - just like any other STORED calculation.

but what is it that triggers the initial calculation ?

What triggers the initial calculation of a non-global stored calculation field?

[Genx]

Well right, but stored calculations have initially been evaluated on the basis of a given record and hold that value permanently until a change is made to a referenced field, a global however will revert to the initial unhosted value at the conclusion of a session - hence the question as to what triggers the initial calculation.

If a global calc references a field, and a record is navigated to thus effectively changing the value within the global calc, would the global reevaluate?... I mean what's confusing me is that it's global, it doesn't relate to any record so that shouldn't really trigger a re-evaluation, so how can you compare it to a stored calc which is tied to a specific record and therefore has clear rules as to when it will evaluate...

Edited October 28, 2007 by Guest

[David Jondreau]

I would have tought creating the global calc triggers the initial value, just like a standard calculation. But I just ran a test and as Barabara noted, that doesn't appear true. If I create a new global calc in a table with no records, the Data Viewer (and a field on the layout) shows a null value. If I create a record, voila, value. If I delete the record, the value persists.

I use them instead of unstored calcs for relationships. Usually =1 or "Employee" (for filtered value lists). I don't know of much advantage of unstored to global (except the existing record thing), though perhaps comment's post about globals not recalcing whenever a layout is drawn applies to relationships too. Some have experienced problems with them, but I haven't.

[comment]

I am not comparing it to a stored calc - it IS a stored calc.

a global however will revert to the initial unhosted value at the conclusion of a session

A global field will - a global calc won't. It cannot revert to some initial value, because it has no initial value - it is a calculation.

If a global calc references a field, and a record is navigated to thus effectively changing the value within the global calc, would the global reevaluate?

It will not, since navigating to to a record does NOT effectively change the value within the global calc. Such description fits an unstored calc, not a global calc, which is STORED.

I cannot stress this strongly enough: a global calc is first and foremost stored - only then global. The only difference between a non-global stored calc and a global one is that the global calc returns the same result for all records. Regarding the question when is a global calc evaluated, there is no difference between the two.

[Genx]

Any examples of when you have used a global calc in place of something else?

[comment]

If I create a new global calc in a table with no records, the Data Viewer (and a field on the layout) shows a null value.

And if you create a 'standard' calculation field in a table with no records?

[comment]

Any examples of when you have used a global calc in place of something else?

I'm afraid I cannot answer that - my brain doesn't work that way (what is a good problem for this solution?), and neither does my archive.

[Genx]

Any examples of when you have used one to solve a problem then?

I think I get the Gist but i don't see much use for it other than as a static value or a static calculation which will essentially return a static value... unless global calc's re-evaluate when a referenced global changes.

[comment]

Any examples of when you have used one to solve a problem then?

It's the same question as before... You have two examples in the threads I linked to earlier.

unless global calc's re-evaluate when a referenced global changes.

The DO re-evaluate when a referenced global IN THE SAME TABLE changes.

--- EDIT ---

A better way to put it:

The DO re-evaluate when a referenced field IN THE SAME TABLE changes. The field can be global or 'standard' (but not an unstored calculation, of course).

Edited October 28, 2007 by Guest

[David Jondreau]

All right, let the testing begin...

In a table with no records, a new global calc shows null (if you modify an existing global calc you get whatever the value last was), a new standard calc shows null and a new unstored calc shows a value.

When I create a new record, the standard and the global populate.

If I delete the record, the standard reverts to null, bu the global persists.

I don't know yet what any of this means because I don't yet understand comment's explanation. I think I'll need to reread this thread a few times before I get it.

[Genx]

So let's say I wanted to track the last price changed in a table... If I simply set the result of the global calc to be equal to that field, would that work, and given that this is not exactly a global field, is it's value still session specific or is it truly global across both the tables and all sessions?

[David Jondreau]

Any examples of when you have used one to solve a problem then?

I think I get the Gist but i don't see much use for it other than as a static value or a static calculation which will essentially return a static value... unless global calc's re-evaluate when a referenced global changes.

What do you use for a static values?

I think there's two questions. One is the benefit of a global calc over global "set-by-script-on-start-up". The other is global calc over unstored calc.

[David Jondreau]

So let's say I wanted to track the last price changed in a table... If I simply set the result of the global calc to be equal to that field, would that work, and given that this is not exactly a global field, is it's value still session specific or is it truly global across both the tables and all sessions?

What do you mean by "session"? I think of "truly global" to mean it DOESN'T work across sessions. Well, depending if you're a host or a client). I think in terms of the client, not the host.

Since it's a global field it's session specific for a client. You can set a global calc to a number field. When you change the number field, the calc will change. Another user can put another number into that field and will have a different value in the global calc.

One example that comes to mind is from a layout, a user wants to see, in a portal, all related records that have a EndDate after a user-selected date. I have my GlobalDateField < EndDate.

But what if I want to include in that portal all records with an empty EndDate too?

[Genx]

One is the benefit of a global calc over global "set-by-script-on-start-u p"

You know I'm not sure I agree with you there. I see no benefits of a global calc over a standard global in that case because I only ever use globals to store values that are truly session specific. I.e. a user's ID and user preferences from a user table for example.

Static values, i.e. "1" or "Employee" I always use unstored calc's for... they're on the left side of the relationship so the lack of indexing doesn't really matter - or if worst comes to worst and this table has to be in the middle of a relationship for some reason, a stored calc. The time it takes for FileMaker to calculate that "1" means "1" isn't really an issue for me.

In terms of globals I was trying to refer more to the word than the behavior of a global field within FileMaker.

[comment]

So let's say I wanted to track the last price changed in a table... If I simply set the result of the global calc to be equal to that field, would that work

Well, it would "work", in the sense that it would show the last modified price in the entire table. Not sure what it's good for, though.

Let me try a different explanation: suppose you define a global text field, and make it auto-enter a calculation. Let's say the calculation references a non-global field, a global field, an unstored calculation field - all in the same table, and the same mix of fields from a related table. Do you know when this field will re-evaluate? Because a global calculation will re-evaluate in exactly the same way.

is it's value still session specific or is it truly global across both the tables and all sessions?

I cannot test this, but I believe it should work this way: if a user does anything that will cause the global calc to re-evaluate, the new value is now true for ALL users. An interesting test would be to make the global calc equal to a global field, and see what happens when one of the users modifies the global field.

[Genx]

I cannot test this, but I believe it should work this way: if a user does anything that will cause the global calc to re-evaluate, the new value is now true for ALL users

Yeh that's actually the way I would expect it to work, but I just tried it out and unfortunately it doesn't work that way .

However, in playing, its evaluation is very much tied to record's. E.g. if you auto enter according to a field in that global calc's table, and the user was to create a new record, the global would auto enter as usual and result in an empty value.

[comment]

I just tried it out and unfortunately it doesn't work that way

You can't just say it and leave it at that. Please explain in detail what you did and what results did you get.

I didn't understand the second part.

[Genx]

Don't worry about the second part its not really relevant.

The test invovled the creation of 3 fields.

1) A text field with storage set to global

2) A text field with storage set to global but with an auto enter calc with don't replace existing value off

3) A calculation field with storage set to global.

For the record 2 & 3 behaved in the same way.

On one client machine I set the global field equal to "test1", and on that machine the calc fields updated to reflect that value.

On the second client machine, the global_calc fields remained empty. I then proceeded to change the value of the global field to "test2" in the second client which caused the calc fields to update in that client. The first client showed no change.

It seems that fields with global storage set to on are in fact session specific.

Edit: I also tried the same test with field 1 being a normal field with non-global storage with the same result.

Edited October 28, 2007 by Guest

[Stuart Taylor]

I have not read the whole thread but have been interested in gCalc for a while.

Here is a very worth while application of it, make sure you look at Comments contribution. I would have thought you had seen this at the time...

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

[comment]

Thanks for reminding that one - it shows another important aspect of global calcs: they display values in Find mode.

[comment]

Thanks.

I may have caused some confusion in my earlier post by bundling the refresh question together with the question about individual values.

I think a good test would be something like this:

TextField = "Stored Text" ;

gGlobalField (Text, Global) = "Initial Value" ;

gcCalc (Calculation, Global ) = TextField & " + " & gGlobalField

On login, both users should see "Stored Text + Initial Value" in the gcCalc field.

Let user A change the TextField value to "Modified Text" and the gGlobalField value to "User A Value". The gcCalc should display "Modified Text + User A Value" for user A, and "Stored Text + Initial Value" for user B. ***

Now, if user B modifies the gGlobalField value to "User B Value", he/she should see "Modified Text + User B Value" in gcCalc, while user A continues to see "Modified Text + User A Value".

---

(***) This is a point where I am not quite sure. User B should perform a full window refresh at this point, incl. flushing the cache, to make sure the value has not been modified to "Modified Text + Initial Value".

Edited October 28, 2007 by Guest

[bcooney]

Exactly, why? It's not record dependent, so why does it need a record in the table (initially, as David has tested)? I was using these in place of Constant=1 and saw this behavior, and backed away fast.

I do think that they are of use for publishing pref values, but again, I'm more confident in the Open script set field approach.

But, it's been helpful to discuss them.

[comment]

I don't know why (a global calc does not evaluate without a record - I assume that's what the question refers to). But it seems to be consistent with the behavior of other stored fields, esp. an auto entered global.

[bcooney]

Yes, that is what my question was referencing, the need for a record. I'm not confident that the global will keep its value consistently, even though it seems to after deleting all the records.

[comment]

Well, then don't use them where there might not be any records. They certainly are a strange beast and one needs to consider their use carefully. Kind of like repeating fields.... :(

[The Shadow]

In FM 6, the "global" was in the field's type spot, which we noticed didn't allow the global field to be of a specific type. It was therefore moved to be just a storage option, giving the global fields a real type.

The remaining question was what to do about calculations - should we allow them to be global also? "Why not" was the resulting decision, but no additional work was put into making them work any particular way, so they should update the same way a normal global field does.

[Genx]

Just thought I'd make a passing mention a few months down the track. I just had to do something ... global calc's retain their value in find mode - standard calcs do not. Probably obvious to most people but ...

Edited February 1, 2009 by Guest

[David Jondreau]

Which make them useful for having filtered drop down lists in find mode, though I not sure what else.