June 3, 200817 yr I have three related tables: Case, Part, and PartBilling There is a one-to-many relationship between Case and Part, likewise with Part and PartBilling In a layout showing records from Case, there is a portal showing the related PartBilling records. However, within the portal I also want to display data corresponding to the appropriate Part (parent data). This parent data does not display appropriately; instead each instance of PartBilling in the portal will only match data from the 1st Part record related to Case (even if that record is not related to PartBilling). What's going on here? It seems as if within portals FileMaker can correctly navigate to child records, but not backward up the relationship tree. Is there any workaround? I would just make the portal show records from Part, but then it will miss multiple child PartBilling records.
June 3, 200817 yr Author Figured out how to do it. It seems that portals are only meant for display related child data, not parent data. The workaround is to create calculation fields in the child table that points to the field in the parent table that you want to display. I made it an unstored calculation.
June 3, 200817 yr First if you have a One to Many between Case to Part and then Part to Part Billing, is this the current way you are using it for your portal? Case --< Part --< Part Billing or do you have a foreign key in Part Billing with the case ID? Please explain your setup along with what your keys for your relationship are. Anyway, if you have a portal with Part Billing and your are referencing the parent TO in Part, it will give you the first related record.
June 3, 200817 yr You need to tack on another TO of Child BEHIND the Grandchild (from the Parent's point-of-view). Then use the fields from this TO in the portal from Parent to Grandchild.
June 4, 200817 yr Author Yes, the relationships are as you diagrammed: Case---- I found exactly as you described: the parent TO shows the first related record.
June 4, 200817 yr Author Gotcha, that worked. It is probably a better way to do it than calculations referencing the parent table. Thanks, - John
Create an account or sign in to comment