Portal inside of a portal.

[Pirsqed]

My current layout is centered around a table containing RMA information. We then have a portal that contains information about individual products. I'd like to add a field that would be for problem diagnostics.

The only problem with this is that a single field per product isn't cutting it.

Thus, my first thought: A portal in a portal!

Well, that didn't work. I would assume it didn't work because the newly created portal is still related to the main table, even though it's inside of another portal. Bummer.

Now, making a new layout that is centered around the products, rather than the RMA records is not an option, as the records are most commonly browsed, and the products are only a concern for a limited amount of time.

To sum up: RMA record is one to many. Each one of those many also needs to be one to many.

I guess I could just make four or five seperate fields, but that is not very conductive to report generating later on.

Any ways to get around this? Thanks very much for your time!

[Fenton]

I see you have FileMaker Pro Advanced 9 in the post, but FileMaker 7 in your profile. Please update it if you can.

If you just need to get the values from 1 related field, then the List() function is easy. To put together several fields, I use a Custom Function, GetRows(), which is available from:

http://www.briandunning.com/filemaker-custom-functions/list.php

(It also requires the GetNthRow() CF, from the same place.)

[ I see that the author, Bruce Robertson, has a new one, which does much the same, but requires only the Layout Object Name of the portal itself (which you'd have to name manually): GetRowsObjectList() ]

This produces, as a calculation field, result text, much the same thing as a portal. So, if shown within a portal, it can produce the same information as a "portal in a portal." If you use a tab as the separator, you can format the field to have decent separation. That however involves some secretarial skills.*

*FileMaker has basic word-processing tools, tab setting, alignment, etc., both within text fields (Browse mode), and within calculation fields with text results (in Layout mode). But I find that not everyone knows this, so I point it out.

Edited June 5, 2008 by Guest
GetRowsObjectList

[comment]

Why not have two portals: one for the children, one for the grandchildren of selected child.

[Pirsqed]

Thanks for the comments, gentlemen.

I'm not at work at the moment, but this is a decent time for me to type this up.

Fenton: Good thoughts, but I need it to be editable, as well. The purpose of the extra field is two-fold. One, to collect more information. And two, to make sure that information is usable later on.

Comment: I had tried that briefly, but it seemed to only want to use the first portal row, and not any others, regardless of which was selected. Now that I think about it, though, this may be because I happened to throw the portal into the header, rather than in the body with the first portal. I'll try that when I get in tomorrow, but I somehow doubt it will be changing things.

I know from experiance, though, that you know what you're talking about. Perhaps I've missed a key step in allowing the grandchildren portal to work properly.

Edited June 6, 2008 by Guest

[Fenton]

As you originally said, there is no usable "portal in a portal." So, my solution is a good one if you want to present the grandchildren as non-editable text. Comment's is a method for entering or editing data in grandchildren row records, in a separate portal.

You'd have a button in the child portal row which would set that child's unique ID into a field.* That field would be used as the originating key of a separate grandchildren portal. So you'd see/create the children of that child, and only that child, in a portal, as editable records.

*This field is normally in the parent table. It can be a global or a regular field. The relationship then goes directly to the grandchild.