You are able to display anything on a layout provided that there is a suitable relationship. A common relationship example is an invoice. From the invoice you use a portal to display line items. There are many line items. In a portal line item you can display product data because there is a many to one link between line items and products. The product link in the line item will only match a single record.
Invoice -|----------< Line Item >----------|- Product
However, if your relationship is more like a cascade then it's harder to display because each item in the list may need to display another list. You need to jump hurdles to display grandchildren in a useful, sensible way.
Parent -|-----------< Child -|------------< GrandChild
Another problem is how you display information that is between the current context and the portal. The rule is that if you display any data that is between the current context and the portal context you will only see the first valid instance. This can cause odd results if there is more than one valid instance. To be absolutely sure you are able to display the correct information should display data from the portal context or data in one to one relationships that are beyond the portal context. In the invoice example above, you can display a line items portal and include "product name" from the products table. If you chose to display a "products" portal on the invoice layout and included data from the line items table, it would not work. To properly display line item data from the Product table you'd need another instance of the line items, shown below as Line Item Copy, and display the data from that TO.
Invoice -|----------< Line Item >----------|- Product -|---------< Line Item Copy
All good info, but I'm going to pick a small nit here as it may help improve on your reply:
"In a portal line item you can display product data because there is a one to one link between line items and products."
This not normally a one to one relationship but rather a MANY to one relationship as there will be many line items that link to the same product (unless your products are cars, unique art objects or something...)
This still allows you to include fields from products in the row of a line items portal since any given line item only links to a single product.
yes, you're right. I'll edit the original.
Mine might be some sort of circular reference problem since the context of the portal row is the same as that of the layout, so when I put a field in the portal row from another related table, it assumes... defaults... to the context of the layout, and displays the data related to the layout, not the portal row, i.e. the same data in all portal rows.
If this makes sense, then my text field solution is probably the simplest solution, since all I really need is a summary for the user to identify and click on.
After another look at the relationship table, I think the problem is that I'm looking at another instance of the RO table through the portal, and THAT instance doesn't have the same relationships as the original... in fact it only has the one "X" relationship. I'll give it a bit of thought to see if there's a simple way around this... it's not worth creating duplicate relationships the the new table instance...
You are mixing up your terminology I think? If you create a portal, the selection box only offers table occurrences (TOs) which are different to the TO that the layout is based on. This prevents you from creating a portal which has the same context as the layout. The only way you could do this is to create the portal on a different layout then copy it back to a layout which has the same TO.
It's OK to have many different TOs based on the same base table. You can put those onto the layout. The TO creates the context not the base table.
That's what the second paragraph I added above is about. After writing the post it didn't sound right to me either... the portal and layout have the same context. I just had the relationship reversed in my mind. The portal context is that of another TO which doesn't have the same relationships as the "main" TO, that of the layout, so I can't access data via these relationships in the portal.
You can have a portal with a different context by creating it in a different layout and copying it back? I'd have assumed it would change to that of the layout. How would this be used?
How would this be used?
Sounds like a way to get a portal that doesn't work.
After another look at the relationship table
And how about showing us the graph?
How would this be used?
If you can find a use for it, let us know. :-)
It's actually more of a diagram than a graph or table, but I'll go with graph
I've pretty much answered my own question, but thanks! If you want to ponder other solutions, the simplest graph would have what you could call the "main" table, which has many relationships, and a second instance of the table with a "x" relationship to the main table,
The portal is in the main table, and allows the user to see all records (filtered) and then go to the record.
This works, but because the second instance has no relationships, displaying related data in the portal isn't possible. I described my acceptable workaround above. If there's a more creative way to do this, I'm always interested in creativity!
Only to keep from confusing others, most of us try to use the terms that are found INSIDE the product:
Relationships Graph it is.
I disagree with a few of the terms. It says table serveral times in the screenshot, and not Table Occurrence. I still perfer usage of the 'table alias'...
It's NOT an ER diagram, that's for sure!
If you want to ponder other solutions,
You will find volunteer helpers here not very inclined to do that if you are so repeatedly unwilling to do the basics that make it easier for the people understand and help. Such as; provide relationship graph screenshots, use standard terminology, etc.
Assuming you meant this for me, understood. Since I understand now why my first solution didn't work and have another one that does, any additional input is strictly educational/recreational so I have no expectation of additional input, especially not from the disinclined. I'll strive to apply your suggestion when I next have a question.
...I'll then have to figure out how to include a screen shot... never done that...