Jump to content

Global Calcs


This topic is 5621 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...

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 by Guest
Link to comment
Share on other sites

This topic is 5621 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.