Assuming one child table to the parent, you can base your summary report layout on the child table instead of the parent. You can still bring your data from the parent into the report to put in sub summary, header, footer or grand summary parts as needed while your child fields populate the body. (except for summary fields in the child which can be included in sub summary parts if needed.)
I am using a layout from child table and using a relationship to show parent, which works great - thanks.
But I was trying to use a layout from parent table and show related children.
But you can't do it can you?
I have used two go to related scripts to get to the same result anyway Using the first layout above.
"But you can't do it can you?"
Well you can use a portal to list the children on a parent based layout--sometimes you have to do it that way, but you get a lot nicer report if you can do it from a child layout.
The list has to be printable and can also contain unlimited children.
If I could find a way to show a portal which extends or contracts according to the number of children then that would be great
Yes, do it from the child table.
You could put an extremely large portal on the layout and set it to slide up but why do it that way when a report from child is so much more flexible?
The child table is two relationships away.
So I have used two go to related scripts to get to the children I want to display in a new window. It works like you say. Just a long way round to get the result I want.
The child table is two relationships away
Then it's not a parent - child relationship anymore.
Anyway, like Phil says, when you report on a 1 to N relationship, you always go where the N are and do your report there.
I guess that would be a grandchild
I go to first children related and show and then do it again to get the list I need
As long as your relationships are:
Do the report from C
and you can usually do a GTTR from A that specifies C to get the found set that I need for my report.
when you report on a 1 to N relationship, you always go where the N are and do your report there
"always" is a little strong.
how about "mostly"? There can be times when it does make sense, if there is P-<C-<GC, that you would report from the middle. And there are complete workarounds where we push values (from all related records) to a temp table and go from there.
Yes, we have been recommending the generally best approach. Note that I asked why marcx did not want to use the grandchild layout for the report. So far, no reason has been given that makes it a bad option.
A common case for not using that layout is when you have a parent or child record with no grandchildren and you want to include it in the report. Then you are stuck using three less than ideal options:
- dummy grandchildren
- Report table