You need to set up your report using a layout based on the portal table. Optimizing your use of the space on the printed page is exactly why you would base your report on such a layout as it provides the maximum possible flexibility in generating reports.
You can perform a find or use Go To Related records to reduce the found set of Activity records to just those you want in your report.
PhilModJunk: thank you for your input. I investigated that option: unfortunately, the Main table "jobs" contains a notes field which can contain as many as twenty lines. I have generated the list view report based of the activity portal table - unfortunately, when I include fields in that record from the parent jobs table, one field "notes" can be 20+ lines potentially for each portal line item entry. Is there some way to conditionally include a field in the first appearance of a record and not subsequent appearances?
I have also attempted to put information from the parent table, like the notes field in a header (in this portal list view report), it simple does not look good or maximize the space well.
Add a Sub summary layout part to the report layout. Specify "when sorted by JobID" or some other field in Jobs or Activities that uniquely identifies the job.
Put your Notes field and any other fields from Jobs in this sub summary layout part. You can size the notes field to be many rows of text in height and set the field to "slide up, resize enclosing part" and this layout part will shrink down to just a large enough size to show the data in your notes field.
Be sure to sort your records by this same "sorted by" field or the sub summary layout will not be visible.
PhilModJunk: Terrific Suggestions! Thank you for your help. Look Terrifc!
PhilModJunk: Thank you again for your help. I ran into one other complication:
Since the report is based on the portal table "activity". If I have a "job" in the primary table that does not have any job "activity" an associated portal record is not created - therefore that job is not displayed in the report. I can work around this by having the system create an associated record when I create a new job. . .but for 100+ existing jobs that do not have activity. They are missed by the report.
Is there any way to capture the "active" jobs from the primary table but use the portal table to build the report?
. . .I have created a workaround (scripting): when I create a new job, I automatically create an associated record in the "activity" portal with today's date and "Job Created" entry. . .I'll dummy in something for existing jobs unless you or anyone has a good suggestion. Thank you again for your help and input.
That requirement will make you evaluate different trade offs as FileMaker lacks the kind of "join" that would allow us to pull in data from Job records that do not have a matching activities record in the report's found set.
One approach is to use a list view layout based on Jobs with a portal put in the body of the report. A portal can be put on your layout that is many more rows in size than you expect to ever need for your report and then set to "slide up and resize" to shrink it down to just the number of rows needed for your report. That can create issues however with getting page breaks in the right place and you lose the ability to have individual fields inside the portal row slide up if such are needed.
The other option you have already mentioned, you set up some "dummy" records just to ensure that at least one record exists in activities for every job record. One way to do that is to have a record in Activities be automatically created that is empty of all values except the match field and some kind of "flag" field that identifies it as the dummy. When you perform a find to pull up the Activities records that you want for your report, you also include criteria in a second find request or an extend found set that will include the "dummy" records in your report. Since your other fields in the dummy are empty, most summary field type calculations that you might set up for your report should not be affected by the inclusion of these dummy records. This approach is not ideal, but may be a better option in some cases than using the portal.