I have a situation where I'd like to have a "Person" layout use a portal for display of possible multiple "locations" like a home address, vacation address, work address. I'd then ALSO like each "location" portal row to contain a display of possible multiple phone numbers (voice, fax, modem, etc.) that might be associated with each specific location.

My first attempt was to simply place a "phone" portal inside the rows of the "location" portal. Doesn't work... naturally, the "phone" portal is always evaluated in the context of the current "person" record that is the basis of the overall layout. It always displays the SAME set of numbers regardless of which "location" portal row is being looked at.

Seems to me that SOMEONE MUST have done something like this already. Are you willing to share the key concept that got it working?

Thanks MUCH!

Hi Larry,

Personally, I'd tie Phone Numbers directly to the Person, rather than to their Locations. I think if you're trying to contact someone, you'd rather see all of their Phone Numbers at a glance, than to have to drill down into each Location. The Phone Type ("Work", "Home", "FAX", "Cell", "Pager", etc.) can then just be an attribute of the Phone Number.

But to answer your question, since you can't nest portals, you can use another technique to show the contents of a second portal (to the grandchild table) when a row from the first portal (child) is selected. This is easy enough to do by using a global field to hold the value of the selected child's primary key, and have that set by a script that's executed by a button on the child portal. You'd then need a relationship from this global to the grandchild table.

Ender,

Thanks for the thoughts. I've entered some additional thoughts below...

I think the direct link between phone and person is perfect for MOBILE phones that are NOT tied to a single location. In fact the application in question ALREADY provides THIS capacity...

However, if you are managing information about several LOCATIONS for a person (vacation, office, lab, home), it is often a benefit to offer the explicit link between phone number and location...

In fact, I already started a solution LIKE the one you suggest. However, at current, users might move from one "person" record to another WITHOUT using developer-provided scripting. So the problem arises of how to ensure that the global storing the current "location" key is "reset" whenever the user moves to a new "person" record...

I've had the hunch that a calculation based on the "evaluate" function might get me there. But so far I've not been successful. Ideas?