1 of 1 people found this helpful
If a layout is not listed in that dialog, it is not a layout based on an occurrence of the same data source table as the table occurrence that you specified as the "Get Related Records From" table earlier in the same dialog.
Say your want to get related records from "Table A". "Table A" would be the name of a "box" in your relationship graph. If you check that box, it might have "customers" as it's data source table. If you found Customers on the tables tab, you'd find that "Table A" was listed as an "occurrence" of Customers.
With that table occurrence selected, you can select any layout based on an occurrence of "Customers". That might be a layout based on Table A or it might be a layout based on a different occurrence of customers.
Thank you Phil.
I understood what you said. I actually have a lot of portals running with the "go to related layout" feature without any problem.
However, in this specific case I am using portals with virtual lists. I am using the ExecuteSQL function to get some data, and then populate a portal using a virtual list table occurrence. According to the manual, I need to create a cartesian relationship between the virtual list table and the main layout I am in. I did that, the portal is showing the data as expected.
However, if I try "go to related record" from the portal row, I have to select "show related records from:" the data from the virtual list table occurrence which the portal is getting the information. It seems a problem with the cartesian relationship or something else.
Better read my last post again then. I don't think that you do understand.
A Cartesian relationship won't be the issue here as far as I can tell.
Perhaps you can sketch out the actual relationships for me and what you are trying to do with GTRR? Maybe a screen shot of the relationships graph?
I am wondering if you'll need a "two stage" GTRR where you pull up records on layout A, then use GTRR to pull up records on Layout B to get the results that you want, but that's just a wild guess at this point.
1 of 1 people found this helpful
to make sure that it is not a Cartesian issue, add a new field called _constant and make it a calculation "1". add in both tables the virtual and the source table of the layout.
Make the relationship based on the _constant field instead of the Cartesian method
try your go to related records step again and if it goes ans shows properly then you know that the Cartesian relationship for whatever reason is not working in that case.
also not to forget to make the _constant field indexed. to be sure index it on both sides.
that relationship change should not make any difference. See these screen shots:
I have a cartesian relationship between parent and child. I have one layout for each occurrence of child with the same name as the occurrence.
I put a button on the Parent layout and select GTRR as the single action as a quick way to open the relevant dialogs:
All of the child layouts no matter the occurrence, are selectable as the destination layout for GTRR. What matters is that each occurrence of Child has the same data source table: Child.
2 of 2 people found this helpful
I have built a portal which displays the results from a virtual list. What I want to achieve here is to go to the related record by clicking in the portal row information.
Don't forget that a GTRR just produces a found set; you can achieve the exact same thing by taking the ID of the clicked portal row and doing a search in whatever layout that is based on any relevant TO. No relationship needed.
you did say that the layout based on the Cartesian relationship does not show.
That's why I suggested using the _constant relationship in case it was a problem.
But if the layout does not show for the gtrr that means that the layout you want to go to is not related to the to the layout you are on.
I think it may be an issue that you are trying to go to a related record from a portal line item.
If that is the issue then use Mr. decorate<s suggestion to simply set the id or the related id from the portal record as a variable and go to the layout you want to and find.
"But if the layout does not show for the gtrr that means that the layout you want to go to is not related to the to the layout you are on."
That isn't 100% accurate. See my screen shots. The table occurrences of the other child layouts are not related to Parent yet can be selected for the GTRR step. This can actually be a useful way to jump context from one table occurrence group to another.
Well, from what I understand go to related reord means just that.
the table occurrence that the layout is based on must be related to the table occurrence of the parent layout in order to see the layout options you can go to.
To test that doublecheck if there is a valid relationship from the layout you are on (not the portal table occurrence, but the table occurrence that the layout is based on). If not then simply create a new layout with the proper table occurrence of the relationship you need and you will see it.
If you don't see it then it means that in some way it is not related.
go to related record
"the table occurrence that the layout is based on must be related to the table occurrence of the parent layout in order to see the layout options you can go to."
Again, please look at the screenshots in my previous post that prove otherwise. However this was coded by FileMaker, it appears that GTRR does pull up the correct group of related records, but can then use any layout with an occurrence of the same table to show that found set. Thus, a layout with a table occurrence that is not related to the original layout's table occurrence can be used to display the results of the GTRR IF it is an occurrence of the correct data source table.
Thank you everyone for the feedback.
I've managed to get it sorted. I gave up on the virtual list feature and started to think of a portal to display the information I wanted.
I created something like this:
The cartesian relationship on the right gives me the details I want, and then I am duplicating the portals and applying different filters for them. Might not be the perfect solution, but I managed to get that relationship sorted.
Thank you all.