This is normal behaviour. The workaround would be to link the grand child TO's to the master via global fields in the master that are set to the id of the child portal record when selected. A transparent button on portal row would work or a script trigger (on object enter ) on the portal. Maybe a commit would be necessary, but it depends. Testing would be best.
There is nothing built-in and easy to use in FileMaker, but it is possible to build it from scratch. Google "FileMaker hierarchy" , there are lots of articles. I like this one, although it does not use a portal:
It is a better approach, as a portal with a complex hierarchy might have performance issues
There is nothing built-in and easy to use in FileMaker
I would disagree, handling data between UI and database, search, navigation through records, security and many more are built in and fairly easy to use compared to SQL solutions. Filemaker users take it for granted sometimes. It's only when more complex issues arise that the slope can get steeper. Just like in any other systems.
Infinite Hierarchy is a very nice "virtual list workaround", however can be quite complex to put together. Could it be used for manipulating data, which is easy to do with a TO and a portal?
Or is it more of a "display only" thing...
On my experience hierarchies are used for display and navigation mostly. navgme did not ask for modification of data in his question, but this could be a requirement, so point taken.
By stating that there is nothing built-in I meant that there is no object similar to portal, which is called "Hierarchical Portal" and you can drop onto layout and setup in a few minutes or there is no special setup in the portal object which will make it hierarchical. I think this is that clarkm was actually asking
I do agree with electon, FileMaker is a good tool to accomplish this task, but as I said, it still require some work .
This solution may require a tree structure like a bill of materials in the future, so it is good to have the reference to the tree view article.
For now, it will be a three level hierarchy Master Series -> Series -> Book. I do not need it to display as a hierarchy right now. The Master Series is the context of the layout and will not vary on the layout. The series and book will need to vary.
It seems strange that the portal allows for selecting multiple TO's but does not display the middle TO row fields properly. To confirm, if there is a portal containing both the series and book information linked to master series, the series data will show the first rows fields, not the row linked to the book?
Essentially I would like the portal to show the SQL:
- Select Series.Name, Book.OrderInSeries, Book.Title, Book.Author, Book.Genre
- From Series, Book, MasterSeries
- Where MasterSeries = <Current row of MasterSeries>
- and Series.IDf_MasterSeries = MasterSeries._ID
- and Book.IDf_Series = Series._ID
- Order by Series.Name, Book.OrderInSeries, Book.Title;
If the portal only supports one child level linked to a non-varying parent, then I understand from the reply to the original posting that two possible solutions are:
- Add two portals. One for series and one for books. Use a scripts and triggers to show the books of the selected series, or
- Build a tree view