Resource on figuring out how FM evaluates context?

[Justin Close]

Hey all. I hope that I have a simple question, but it has been evading me. I am looking for a thorough explanation of how FM evaluates context and relationships. I know that I have seen in the FM Help "there are two starting points possible for evaluating a relationship..." but it doesn't explain how it decides which of the two to start from.

My particular situation: I am having troubles getting a portal to display what I want. I have three tables that are of interest in this case: Users, Searches, Lines. The layout is based on Users. I have a portal on one side that shows Searches, and I am trying to get a portal on the other side that will show the line items for the selected Search in the left portal. Relationships are pretty straightforward: Users::UserID = Searches::CreatorID, Searches::SearchID = Lines::SearchID_FK. I have tried various instances of TOs with different relations, but nothing seems to have quite worked.

There is one additional feature: any 'Search' can be shared, and so should be visible to any other user. I have a different TO for those searches using a Cartesian join. This Shared portal is actually also on a tab structure in the left side: one tab for Your Searches, one tab for Shared Searches.

It all seems to work fine for my own personal user account, but the line items aren't showing up for other users.

Anyway, I am trying to understand the underlying functionality so I can design a deliberate solution instead of trying the shotgun method. I would think that this would be heavily explained in various places, but I have spent days trying to find such a thing, without any luck. So I am hoping that someone out there knows of a good resource.

Thanks,

C

[comment]

I am trying to get a portal on the other side that will show the line items for the selected Search

A "selected search" does not exist as such. However, if you place a button in the portal to Searches to set a global field in the Users table to the clicked search's ID, you can then construct a new relationship (using another occurrence of the Lines table) as:

Users::gSearchID = Lines 2::SearchID

and base your second portal on that.

[Justin Close]

Yes, that is what I have set up (well, very similar): A global field in the Searches table for the selected search, update via a script trigger on portal row selection. I had tried that setup a few times, and thought that it wasn't working. But some of the testing I am doing now isn't quite working, but isn't showing a blank portal, either, like I thought it had in the past. I will have to do some more messing around with things.

[Vaughan]

I am looking for a thorough explanation of how FM evaluates context and relationships. I know that I have seen in the FM Help "there are two starting points possible for evaluating a relationship..." but it doesn't explain how it decides which of the two to start from.

You tell FM what the context is. This is done by

the TO of the current layout

the TO of the portal display the related records

the TO selected in the "context" in the field's calculation box

Context is then worked out with the layout, portal etc as the starting point. FMP does not allow circular or multiple paths around the TO graph, so there can be no ambiguity about that the context is.

[Justin Close]

So the context of a portal is the "show related records from..." definition? What about scripts that are activated from a button on a portal row? (It sticks in my mind that I read somewhere they had/might have a different context.) Are there other things that might change the context POV of a portal? I think that much of my original confusion stems from using a global as part of a relation ship, and expecting it to work the same in reverse as it does forward (i.e. gSlctr -> ID == ID -> gSlctr). But it doesn't.

More in a moment...

[Justin Close]

Or there would be 'more in a moment' if I wasn't getting 'Must enter a post' and 'post too short' errors here on the forum. Maybe 'post too long' I could understand...

(Trying to post it in stages:)

I have come up with some tests of TOs and have discovered an odd behavior in my system. This oddity may also have contributed greatly to my confusion.

I thought I had things working well from the point of view of my own personal account/login. My portals were working great. Then I had my co-worker give it a test and he wasn't seeing things in the portals the same way I was. So, some more digging and trying out new portal relationships. In doing further testing with other Users (i.e. doing a FIND on the User-base-table for the layout to a user account other than my own) I discovered that apparently all users weren't showing correct info UNLESS they had gone through the process of making a 'New Search' in my UI. I haven't stepped through the scripts yet to determine exactly where the change happens, but I think it is during the creation of a few new records.

(continued in next post...)

I mentioned 'blank portals' earlier, but then thought I had imagined those. Well, I have rediscovered them. Here as screen shots of some different users (same login account to the DB, but different 'FINDs' on the User table). They show one user, 335, who has gone through a 'New Search' routine and thus shows correct information in the portals. Another user hasn't done a 'New Search' and shows blank portals. I swear that is the only thing to change between the views (the User_ID find)!

In the 'Lines' portal in the lower right there is a filter; in 'Lines2' and 'Lines3' there is no filter, they just rely on the relationship.

[images]

(Side note: The 'Shared Searches' portal on the left side is based in 'Searches 2'; the 'Your Searches' tab portal is based in 'Searches'.)

(It really doesn't like images to be pasted into the body, apparently. Trying as attachments.)

(continued in next post...)

I have thrown a lot of fields around to try and figure out the what each context was, so you can possibly see some of the different TOs I am testing. I have also included a screen shot of the Relationship graph showing most of the tables. What you can't see is the USERS table and its relations; it has these two branches of relations:

Users::UserID = Searches::CreatorID

Users::UserID X Searches2::CreatorID

[image]

So, I am going to try and trace down exactly what step it is that appears to be making my portals work correctly, but I am, obviously, unable to figure out at the moment why going through some script steps would make a user 'work' all the sudden. And that 'work' state seems to be permanent; I haven't yet seen a user revert to a 'non-working' state.

-- C

(Done, with this posting at least. )

(What?? And then it seems to have stitched my postings together! Grrr... Oh well, I realize I could have done it in one post if I had used attachments in the first place.)

Edited December 12, 2011 by Cronk

[Justin Close]

Well, I have been able to narrow it down to the presence, or lack thereof, of the user's UserID being present in the Searches table as a CreatorID. That is why doing a 'New Search' made things (the portals) appear to work. Now...why? I obviously think that it should be working all the time.

The Shared Searches should always be available to anyone who comes to this layout, regardless of whether or not they have a Search in the table associated with their UserID. They should be able to see the selected Shared search line items in the portal. More digging.

[Ron Cates]

Observation from a couple posts back.

Comment said

"However, if you place a button in the portal to Searches to set a global field in the Users table to the clicked search's ID, you can then construct a new relationship (using another occurrence of the Lines table)"

You said

"Yes, that is what I have set up (well, very similar): A global field in the Searches table for the selected search, update via a script trigger on portal row selection"

Notice Comment suggests a global in the Users table.

I'm guessing your troubles are related to a global field being used in the wrong place. That's why when a user starts the portal is empty because the global is most likely cleared out. When they create a new search it populates the global and therefore completes the relationship and shows records in the portal. but when a new user comes along the global starts off blank again.

Searches::CreatorID isn't set to global is it?

[Justin Close]

Ron,

No, CreatorID isn't global; it's a foreign key. Yes, I noted he said "Users", that's why I noted that it was 'similar'.

The global isn't the issue; the global gets set when a user clicks a portal row, and that is functioning just fine. I discovered that the issue was due to my relationships. With no UserID recorded as a CreatorID in Searches, the relation from Lines2 wasn't returning anything. I was able to recreate this by manually changing a CreatorID in the table back and forth (i.e. UserID there, lines showed; UserID gone, no lines). A test portal using Lines2 was showing lines, while Lines and Lines3 weren't. Lines and Lines3 are part of a TO branch that has Users::UserID = Searches::CreatorID, then Searches::_SearchID X Lines::_SearchID_FK, and Lines3 was Searches::gSlctr_Search = Lines3::_SearchID_FK. Since there was no UserID = CreatorID connection it appears that those Lines TOs were failing until there was at least one instance of a UserID in the table. Not exactly sure how that was working, but that is the jist of it.

Additional note: What's the context when I 'go to layout...' in a script? I am guessing that it is the destination layout, and all future references will be evaluated from there.

In my project the portal for criteria lines (lower right) can make calls back to the Searches table (I track the number of line items in certain groups back in a field in Searches, so need to update that field at various points). Yet this is also called (I have a helper script) from a button on the main Users layout. I was thinking that a 'Set field by name' might work here, instead of a regular 'set field', but haven't tried it yet. But, even though I am launching the script for the portal on a different TO branch, couldn't I just switch to a layout that uses the other TO branch and thus utilize the _SearchID = _SearchID_FK relationship of that layout instead of the gSlctr_Search = _SearchID_FK relationship of the original branch?

I am slowly working through my scripts to try and iron out all these bugs, so haven't been able to determine exactly, yet.

-- Justin

[comment]

Additional note: What's the context when I 'go to layout...' in a script? I am guessing that it is the destination layout, and all future references will be evaluated from there.

That is correct. Going to a layout establishes a new context.

I didn't understand the rest of your post or any of your previous ones.

[Justin Close]

Yeah, trying to figure out other people's stuff is a pain. Sorry about that. :)

[comment]

trying to figure out other people's stuff is a pain.

A lot depends on how the other people present their stuff... :hmm: