The obvious answer would to do the report in Incidents, and show whatever values you need from the other two tables, since Incidents has a good relationship to each.
But you've said that you have thought of this. So we (me anyway) kind of wonder that is this report which has a problem with this. Perhaps it just doesn't look like a report, since a lot of records would likely have the same value in the field.
The tool to put a layout in "group" order is the Sub-summary part, "Sub-summary when sorted by" (then choose which field to use); you also set the sort in a script. The sort should be using the same order as the sub-summaries on the layout, and should have a "leading" then "trailing" (automatic) if you want to show the same sub-summary part twice on the layout (for totals, etc.).
It is optional whether to include the Body part. If so, it would be in between. If not, you might want calculation fields, to put together numbers (or text) for the sub-summaries.
That's the general idea. Let us know a bit more about the report, and someone will tell you more (and/or better :-).
Set up your report layout based on Incidents and include two very tall portals to each of the related tables. Use sliding and visibility settings in the inspector to set them to "slide up" and "resize enclosing part". these portals will then shrink to just the number of rows needed when you print, preview or save as PDF from this layout. The portals can't expand so you need to start with very tall portals when you design the layout.
There are limitations to this type of report so it may or may not work for you, but it's the simplest approach to try as your first approach.
Look at the data in your two related tables if the data from one or the other does not work well when presented in the report from a portal set to slide, base your report layout on that table, include your fields from Incidents on the layout and then add a portal to the third table sized to slide and resize as described in option 1.
Option 3: (Don't go here unless all else fails, this one's very messy and takes a lot of effort to get it to work.)
Set up a 4th table as a temporary report table and define sufficient fields to hold data from either of the two related tables in your current setup. Link it in a relationship to Incidents. When you need a report, a script finds and imports the needed records from both related tables into this combined temporary table. Design your report layout to be based on this new table. To get the report to look right, you often have to "layer" different fields that only hold data for records from one of the two original tables on top of each other and use conditional formatting or calculation fields that function has field labels for a record from one table and which are invisible for record from the other...
Key facts about sliding layout objects:
- It's only visible in preview mode and when you print/save as PDF...
- Sliding fields will shrink but not expand.
- All layout objects below and in the same layout part as the slide/resize field need to also be set to slide up and resize.
- Objects in headers and footers will not slide.
- Portals will shrink/slide to fit the number of rows of records, but fields within the portal row will not shrink/slide.
- Fields will slide up only if Top alignment is specified for it and will slide left only if Left alignment is specified.
- Consistent side borders are difficult to achieve with sliding fields.
Thanks so much!
You both solved my problem and gave me some great info on using the those features. I'm finding FileMaker to be a great product along with a great community of users!