1 of 1 people found this helpful
Don't try to print from a portal. It generally ends up being a world of pain for things like page breaks.
If you really need to print the portal - you can try creating manual page breaks with multiple copies of the portal (page 1 and page 2 instances on the portal, where portal 1 displays rows 1-10 and portal 2 starts on row 11) or the best solution is to try to print from the table with the child records.
As for the detailed descriptions - use a smaller font. For printed versions, 8pt should suffice.
There are also tricks - I think Kevin Frank had one for really long items where paragraphs of text were broken into multiple records for printing.
You may also run into problems with different printer drivers and x-platorm issues.
I agree with David. Portals are not intended for printing, only screen display. You would be much better off developing the print report in the child table. As you have found already, you will have a few issues to confront, but you are much more likely to end up with a satasifactory report at the end.
I print portals all the time. In them I show the related info of a student: their grades, their behaviors, their test data.
I think portals can be printed when the occasion calls for it: it is impractical, I think, to create a report that shows many pieces of related data from many different tables for each student.
To this post's point, all of the portals are contained on one sheet, so there is no problem of page breaks. That I see is a reason not to print portals, but in my case, it is perfectly fine.
I was not suggesting you CAN'T print them, just that that is not what they are designed for. Provided you can be sure the data in the portal will fit on your report (and size the portal accordingly) there's no problem. And, I agree, if your requirement is "a report that shows many pieces of related data from many different tables for each student" then a report from the parent (ie.student) table makes sense.
Cool. When I first heard that idea that portals are not meant to be printed awhile back, I freaked out because that's how I designed reports. Then I realized its okay to print them for certain circumstances (like what I do).
I think the advice to not print portals is sometimes a little overdone. It's just important to understand how they work and their limitations.
We do have control over the starting row number and row count of a portal - so they actually can be pretty versatile, and you can page break them intentionally where you want to page break them and you can design multi-page forms.
" a world of pain for things like page breaks " is pretty much the answer I needed.
I summarize that portals are just not useful for printing flexible-length reports. One detail I missed out including in my original presentation was that, yes, I have two other tables, in portals, on the report, similar to other discussions that this thread called into question; 3 different tables summarized on one parent table in fact. Each table includes quite different sets of data.
FYI I had developed a version of the report that included a cover sheet summary with each of the tables on different pages. The main body of those pages being the list-view of the sub-tables. Each table started a new page. This provided me with the ability to display full information from each record of each of the three tables. Page breaks were clean when the records were on multiple tables.
My client wanted a different print-out: everything on one page as much as possible.
I'm disappointed that FM does not give the ability to control the break between records on a portal. It seems such a no-brainer that you'd want to include multiple things on a single report, so I thought I was just doing things wrong! It's nice to know that it was the system, and not me, that was so limited, but it still leaves me with no real solution to creating the report I want.
Your last post indicated that your client is pretty exacting in the format of the reports. While you don't say how often these reports are performed, sometimes it worth considering a separate table (or even file) for reports. Also bearing in mind that the report requirements may change occasionally or often.
One of the advantages is that with multiple imports from various tables you get a "flat file" with all the information and not muck-up your base working file. You can more freely use summary fields and unstored calcs without slowing down the main file. It is more work and not right for every situation but sometimes .... it produces exactly what your client wants.
This may be the ultimate way I go on this, usbc. I've already started working with this concept and I see the value in it.
I created a new table that works as an inter-mediator between the details data in the subtables and the parent record table. When creating a new sub-record in one of the tables, I first create one of the intermediary table records, and then relate that to a unique ID on the sub-item. Your post turns on a light that I could then use each of the intermediary table records as a body item, and create the report in that table, since the body items should break properly. I can use related items in the parent and the child to build the report.
As a bonus with this method I can sequence the subitems across the report, from any table, which is something my initial report design didn't permit. For instance in the original design, I could sequence in each portal, but I couldn't put a record from another table mixed into the sequence. but with the intermediary design I can. If that's hard to understand, let me draw a picture:
Table One Portal
Table Two Portal
Table Three Portal
Table One, Record One
Table Three, Record One
Table Two, Record one
Table Three Record Two
It's a lot more flexible in the report, but way more complicated in the structure. The big problem is that it's limited in what I display in the intermediary file; the data in each of the subfiles is quite different!
Glad that caused a spark. In the end you will know what is best. And while creating a record in your report table will work... When I do use this approach to reports, I view it as a "Catch and Release" metaphor. [import / delete, wash rinse repeat] So I will have a field in the report file to accommodate each and every "unique" field in the various source tables. Then in the report file the self relationships can be limited to the base entities like Company, Invoice, Salesperson, etc. The rest is done by scripted (local) finds and layouts with sub-summary parts and sorting script triggers. Occasionally I will display related data from the main system but mainly it is a flat file. This becomes handy because eventually someone will ask for a "cross-tab" report or to export the report to another application.