Go to the layout of your report and enter Layout Mode. Select a field and open the Inspector. In Position tab on the Inspector there is "Sliding and Visibility" section. The behaviour your describe is driven by the two radio buttons - "Sliding left" and "Sliding up based on:". Most probably you need the second one.
Nicolai is correct on how this was probably done. However, it should be pointed out that portals don't adapt well to printing, since they display only a fixed number of rows and therefore can leave data out when printed. It's generally better to base the report on the child table (the one the portal points to) and reference fields in other tables.
I get what you are saying and I get the feeling I should be careful about using portols to much,
but my understanding is that if I try the method you mention above I would only see the first of many records that are related.
In order to see all records that relate to a record in my "base" table I would need to use a portol and show related records from this "child" table.
Am I getting this wrong?
thanks in advance
kinda depends on your workflow. You can also see all the related records by scripting a "go to related records" and showing the related records on their own layout in list view.
Precisely. The report layout is based not on the base table, but on the child table.
Damn, I missed the "portol" thing.
I agree with Mike_Mitchell - portals should not be used for printing, but if you want a quick fix, you can try to use sliding.
I suspect now, you question is a bit different - not displaying related records in the portal if particular fields are empty. You can achieve this with portal filtering. Go to layout mode and double click on a portal. One of the options on portal setup is to filter portal and you can specify your condition, e.g. only display records where field A is not empty.
Wim's suggestion of changing context is the one I would personally use. You can move to children records and use them as a base for your report, Parent information could be displayed in the subsummary part of the report
True Mike, but sometimes there may be several portals (different relationships and/or filters) that need printing. Sliding may work if done carefully. And sometimes getting the values into one "virtual table" (from various related records) for reports is the way to go.
Read the entire thread, discuss more, clarify needs, and I'd bet there are ways to help achieve what you want.
Yes, in the case where several tables are involved, more is needed. Nevertheless, I would tend to avoid portals for printing unless I could guarantee all related records will show up. Virtual List would be a better choice (IMHO).
Thanks for everyone's contributions. I realize this is going a little off topic, apologies.
My Database is to organize visual effects for films and TV but for simplicity ill describe what I am after in terms of a credit card purchase scenario.
Say you had a table which listed credit card numbers and there was only ever one record per credit card number.(lets call this CC table)
You also had a table listing all the purchases at your shop and it has a field listing what credit card number was used for each purchase. I then make a relation ship between this field and the CC tables credit card field.
Then you wan to make a PDF which listed all the purchases for a particular credit cards.
One option is a layout based on the CC table with a portal referencing the Purchase table. The benefit of this for me is that I can have more then one credit card displayed and they will be separated on each page.
Option 2 is to have a layout based on the Purchases table,
Currently I have the field from the CC table listing the credit card number up in the header of the layout, then in the body I have the fields that list the purchases. ie no portal.
My issue here is that I need to run a find in the credit card field in the header, then make a PDF, then run a new find, make the PDF....
otherwise I have will have a page that could contain purchases that belong to more then one credit card.
Do I need to script something that runs this find CC# in Purchases layout, make PDF, goto CC table, repeat...?
Or am I missing something ? (still learning FMP....obviously)
Investigate subsummary parts. You would create a subsummary based on sorting the purchases by credit card. This is the "break field", which means every time a new credit card number appears in the purchase data, a new subsummary will appear. Thus, the data are grouped by credit card number, and you can put whatever fields from the credit card table into the subsummary.
Thanks so much to you all,
Subsummary is what I think works best for me.
If I could mark more then one post as correct I would but I don't think I can, so many great comments, thanks for all the help.
I will be taking a bit of everything said here to incorporate.