relation: global to indexed number not updating

[cellmaker]

Hello to all. Long time.

I may be losing my marbles, but something seems oddly messed up.

I have a global in an "interface" table, which holds the field "glYear", which is a global number.

I have two other tables, which are a general "Team" table and a "TeamYr" table. Teams can have many teamyrs.

I have a calculation in Team to pull the global Year into Team, called c_glCurrYear. From this, I have constructed a multi-key relationship to a TOC of TeamYr:

c_glCurrYear = Year

PKey_Team = Key_Team

(PKey is unique idea for each team; Key_Team is the corresponding identifier in TeamYr)

So, this relationship works, which it should. Both right-side fields are indexed.

However, the relationship doesn't update when gl_Year is changed. Oddly, the calculated field based on gl_Year updates instantly in Team, but the relationship on which that calc field is based doesn't recognize the change.

No mode changes refresh the related data. No change in record changes it. If I go into Define fields and get a field definition, then come back out (no changes necessary), the relationship updates correctly.

What's up with this?

(I'll belabor this with more info below, but those brighter than I probably won't need the example.)

Charlie

Example

Team 1 (ID 1) has two TeamYrs: 2000 and 2001 (both with ID1 keys from Team)

If global is set to 2000, first record in TeamYr should show up related.

If global is set to 2001, second record in TeamYr should show up related.

If global is set to 2003, nothing should show up.

At first blush it works, but if I change the global from 2000 to 2003, the related info does not change, even though my calculated year in Team updates immediately.

[Søren Dyhr]

So, this relationship works, which it should. Both right-side fields are indexed.

However, the relationship doesn't update when gl_Year is changed. Oddly, the calculated field based on gl_Year updates instantly in Team, but the relationship on which that calc field is based doesn't recognize the change.

I had the same thing yesterday, here did I actually suspect the X (carthesian product) relation to be the buggar, and had to script the matter instead ...during a process where straight forward calc's as well as autoenter globals with the "allow update" chosen as well as an thorough investigation of Evaluates( 's role. This is definately a differnt beast to get the hang of!

What I tried to do was a monkey class dwindle, using a dynamic valuelist to filter a popup - I have a challenge here ......can anyone make this work sans scripting?

--sd

Dwindling.zip

[cellmaker]

Hmm. I thought it might be something to do with the global, or the cartesian relationship linking to the table (Interface) holding the global.

So I eliminated both of those conditions. I no longer use a global, but have simply:

Team <--> Interface (by constant 1::1)

calc Team::c_curryear = interface::year

Again, if I change interface::year, Team::c_curryear changes appropriately, but...

My secondary (multi-key) relationship based on c_curryear does not update. Everything is indexed except c_curryear, but it shouldn't have to be. It's on the left side of the relationship.

This seems totally wrong. Can anyone clue me in as to why this very simple concept refuses to work?

Thx,

c

S

[transpower]

I cannot fully understand either of your posts, but I'd recommend making the field in the Interface table non-global. Also, instead of a calculation field, use Evaluate (with the function enfolded within). Then make a Cartesian relationship between the files. The correct records should now display.

[-Queue-]

S

[Søren Dyhr]

S

[Søren Dyhr]

S

[cellmaker]

S

Testmess.fp7.zip

[transpower]

Do what I said before: de-global glYear and index it. It then works.

[cellmaker]

Transpower -

You seem a bit fed up with me! (Sorry if I seem obtuse.)

Anyway, perhaps I'm doing something different from what you're doing.

I went back into my "global" table and deglobalized gl_year and indexed it, and left the cartesian relationship intact.

I am not getting any different results. My calculated year (based on gl_year) still updates correctly and immediately in Team, but the related records in TeamYr (via the multi-key relationship) still do not update. Did you look at the file I uploaded?

I'm attaching a screenshot of the problem, which shows that the calculated year in Team is correct but the multi-key relationship is wrong.

Any ideas? Is this really expected behavior in FM7?

Many thanks for your thoughts and patience.

Charles

Badrelation.pdf.zip

[cellmaker]

S

Dwindlingcopy.fp7.zip

[transpower]

Cellmaker: No, I'm not getting fed up with you. It's just that I downloaded your attachment, made the two changes, and got the fields to update correctly, exactly as you wanted. So, now I'm just perplexed...

[Ugo DI LUCA]

Hi,

Just guessing as I don't have my copy of FM7 here to test.

Create a simple script of

Refresh Window - Flush Cache...

[cellmaker]

This sort of thing didn't seem to be an issue until I updated to 7v3.

Do you think there's some sort of glitch going on in the OS X version of Filemaker? Wouldn't this have been apparent to many people from the get-go?

Charles

[Søren Dyhr]

This seems to work, although it will only properly update (as far as I can tell) if you create a new record. Otherwise it will not immediately eliminate a new value in entryfield from the "notusedvalues" list.

But you didn't absorb his reply - to make it properly update use Evaluate( with the part I was unaware of the escape coding of the listnames quotes so the syntax turned this:

Evaluate( "ValueListItems( Get(FileName); "Trimmed" )"; [Entryfield] )

....This solved most of my problems except when bulkerasing the entire lot of record. When starting all over again an old valuelist seems to be hanging.

But it's due to the layoutupdate in the related file you could blame for it. The solution is to define a straight forward valuelist sans the catesian ...but with dependencies in the actual layout/table. The reason for duping the TOC was in an efford to solve the lack of updates.

--sd

[cellmaker]

S

[cellmaker]

Well, I tried that, including switching to the "global" table and then returning to the Team layout, refreshing and flushing. No effect. Peculiar, this.

Thanks for the suggestion, tho.

If there's anybody out there using OS X/FM7v3 who could try TestMess.fp7 (already uploaded), I'd appreciate it.

Charlie

[-Queue-]

You're using a related global, not a global contained in the layout's TO, so you need to use the Refresh Window [Flush cached join results] step that Ugo suggested.

[cellmaker]

Ah! I misunderstood Ugo's instructions. I did a refresh step and then a flush cache to disk step, not realizing there was the flush join option on refresh. [Also, it doesn't seem to matter if it's a global or not.]

Many thanks.

All that said, why is this necessary? (Why doesn't it just update automatically? Is this something that has to be done to keep FM from constantly updating relational info? Transpower, in his post above, doesn't mention that he used this script step to get it to work. He's on XP, by the way.)

So is there a way around this?

More info on this would be most appreciated as it would probably save some headaches in the future. I don't want to be setting up a lot of structures in my solutions that involve having to run scripts to make sure they're updated.

Thanks for any (more) info you can give me.

Charlie

[Fenton]

I don't see why you're using a global value in another table, linked via a Cartesian relationship (not needed for globals), then referencing it via a calculation in the Teams table.

The trouble is that you're entering the date in another table, and expecting the calculation to reevaluate. Well, it does and it doesn't. It does, as far as display on the layout; and if you referered to it in a script. It doesn't as far as refreshing the display of portals. This has been true for years.

Why not put the global directly in the Teams table? That way it works.

Testmess_fej.zip

[cellmaker]

Fenton -

You have a point. The Cartesian thing was just one of many permutations and combinations that arose as I was trying to figure this out.

As to your question about why the global is in one place and not another, as I'm developing my particular solution, I wanted to store certain globals in one place, but be able to change that value from any number of different areas (TOs) in the solution. In the past (yes, I'm sort of sporadic in my development needs, so sometimes I forget what I already knew), I've handled this by setting individual globals by script.

I guess I was hoping that, with FM7 and the multi-table construct, I wouldn't have to do this anymore.

What concerns me, actually, is that I could have any number of times when I'll want to show related data in one place based on conditional values set elsewhere in a solution. It seems that, because of this, I can't be sure that things will properly update.

As an example, let's suppose that you had a calculated date that changes depending on some other conditions (days before Today, e.g.,), and across your solution you wanted to see only records (via portals) corresponding to dates greater than or equal to that calculated date. That's a fairly arbitrary set of conditions, but does this kind of concern make sense?

Charlie

[Fenton]

Well, considering that you're really always only looking at 1 window and 1 layout at a time, I don't see that it's a problem. It's hard for me to think of a case where I had to change a value in some central location, and expect all the visible windows to change accordingly. I think a script would be required to refresh each.

I must amend where I said that the result would always be correct in scripts. It isn't, not unless you do something, such as Queue said, Refresh Window [ Cache join results ]. I tried a simple Set Field[] using the relationship; and it return the last result, not the correct one.

That is sort of new to me. But then I wouldn't set it up this way. My rule of thumb is "use what works." If it doesn't work, then whether it's theoretically possible, or whether I think it should doesn't much matter.

So, it something to be aware of. Basically my point was to keep data as local as possible. Just because you can cross TOs to reference globals doesn't mean it will work the same as changing a local global.

OK, here's another way, in the attached file. I've related the central file directly to the filtered "many" results. The Team table looks "through" the global table to see the results. It seems to work fine without requiring a script to reset the gYear.

It stills needs one to reset Team; ie., you can't use the rolodex.

[Deleted nonsense -]

[bTW, you can change the Cartesian relationship from Team to Global table to =. Either works. This could be a 1 record table (which seems logical) those would be regular fields.]

Testmess_fej2.zip

[-Queue-]

I wouldn't exactly say it's passing through. There are two unidirectional relationships, one going from right to left (from the graph perspective), from Globalholder to TeamYr 4 Team globalYear, and one going from left to right, from Globalholder to Team. But the two have no effect on each other, since the relationship cannot go from TeamYr 4 Team globalYear or Team to Globalholder.

You could, perhaps, call it an optical illusion though.

[Søren Dyhr]

Anyway, I don't know anything about evaluate() in this context as yet. It's a bit frustrating that one would need to resort to using a custom expression when a non-stored calculation "ought" to do the trick.

We're still on monkey class just like, we with previous versions sometimes shoud reachout for case(1,theHangningcalc;triggerfield) ...

--sd

[Fenton]

Yes, Queue is right. It does not "pass through" in any way. I wasn't writing (or thinking) clearly.

I was explicitly setting the gTeamID in the global table. In fact it shows the TeamYr records exactly as they would appear if the portal was in the global table; nothing to do with the current Team at all; it appears to be because you're going to its record when you click on the TeamsAll portal.

Basically a layout like this has no business showing data from the current table's record. It's a portable "navigation only" layout; portable in that it could be either IN the data table or IN the global table.

[cellmaker]

I've used the everything-from-the-global-interface method before, which obviously works. I'm just experimenting on different approaches.

Thanks for all your help, everyone. I'll simply avoid the kind of situation I posited.

Now I have to start looking at evaluate(), just to get up to speed on that.

Charlie

[transpower]

I have my XP system set up to flush cache every 2 seconds--so maybe that's why I don't need that extra step.