Printing Portal records

I have a print layout that I am creating in List view. I need to have the Notes that are in a portal for that record, print in the report. I can see the Notes in Browse mode, but not in Preview mode and the actual notes do not print out. I used a text field in the layout referencing the Notes portal. Is this the correct way to have portals on other layouts show up?

I've checked to make sure that the Notes field is not hidden from print in the Sliding and Visibility panel. Perhaps I'm not setting up how to access a portal from another layout correctly. Thank you for any pointers! :)
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Peter HarrisFileMaker Developer at CognitiveCommented:
If I am understanding you correctly, I suggest building the report from the 'lowest' level.
So the layout table would be set to the Notes table and the notes would be in the Body of the report.
You can set the notes field larger than necessary and set 'shrink to fit' for them.
The other fields would be at the higher levels (and must be related to the Notes).
Will LovingPresident, Dedication Technologies, Inc.Commented:
Peter basically said what I was going to say, that you should build the report in a layout based on the Notes table. In order to display the information from the parent record, I would also put a sub-summary  "Part" before the Body part and set it to summarize when sorted by the parent record Id.  Then put what ever fields you need from the related parent record in the sub-summary part and they will appear above the Notes. Also set the fields in the Body part (the Notes) to slide up and the Body part to "Also resize enclosing Part" in the inspector.

Sub-summary partInspector Sizing specs
_Astrid_Author Commented:
I'm still tweaking this to work. I may have an issue with the table relationships since it's not displaying as it should when I print. I'm still working on it! :)
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

Will LovingPresident, Dedication Technologies, Inc.Commented:
If you want to upload an example file or send it direct, I can take a look at it. You want to use a GTRR from your main records to a layout based on your Notes table, setting to show only related records. Then sort your notes in whatever order you want but include in the sort the main record ID and make sure the sub-summary Part above the notes is set for that sort.
_Astrid_Author Commented:
Hi Will.....I'm sending you my file directly. Amongst this printing issue, my notes won't advance to the next row when you try to Add a new Note via the button. :|
Will LovingPresident, Dedication Technologies, Inc.Commented:
Hi Astrid - My first comment addresses your issue about printing Notes. The other two comments address more general issues of database development.

1. Viewing/Printing Notes: I found your "All Opportunites List" based on the Notes table. You almost have this right. However, the sort order needed to make the notes appear should simply be kf_ID_Contact. You probably also want to include a sort by Created_TimeStamp, descending if you want the most recent one on top, but it's sorting by the Contact ID that will get the sub-summary to display the related Contact data correctly. I've added a button on the Opportunity Details layout called "Opportunity WILL" which triggers a script that prints the Notes correctly.

Notes that if the Opportunity has not Notes, it will not be able to use the Notes based layout. I have included a dialog that states this but you could alter that to simply go to and print another layout based in Opportunity Details table that does NOT include Notes, since there are none.

2. Your Welcome Screen is based the Opportunities table. I would suggest that you create a new table called "Start" or "Interface" (or whatever you like) and have 1 record in it. Set privileges such that users cannot delete this record or add other records. Add some basic fields to it (I create a calculation field called "zk_Constant" set to alway equal 1) and create relationships to the Opportunity tables to display your three recents Open and Closed. This is a common practice and is safer than having a screen such as your Welcome screen that is based on, but not displaying the actual record data.

3. I generally recommend that users avoid the syntax gymnastics of trying to name their key fields using pK, fK or underscores. There are a number of naming conventions out there each with it's adherents, but because 1) FileMaker relationships are bi-directional, and 2) you can clearly and visually demonstrate Primary/Foreign key simply by the structure of your relationship table, I suggest that you call the "Contact ID", Contact_ID or something similar everywhere that it is used. The same thing with any other key: use the same name in both tables. That makes if very easy to see if you have the correct key and much less confusing for anyone else who might try to look at your table structure and figure out what you're doing.

Every table should have a serial number based key at a minimum, e.g. Notes_ID, Opportunity_ID, etc. but the fields should be names the same across all tables, e.g. Contacts::Contact_ID, Opportunity::ContactID, Notes::Contact_ID.

Personally I use a system of prefixes as follows (I do avoid using spaces for certain reasons):

All User enterable fields - plainly name with no prefixes, e.g. NameFirst, NameLast, PhoneWork, PhoneMobile
All Key fields used in relationships - prefix of "zk_" - this sorts the key fields to the end of the field list and the "k" stands for key. Primary and Foreign key designations are, IMHO, unnecessary here.
All "Interface" fields - field for button labels, conditional graphics, summary calculations that only appear on reports, etc.  - prefix of "zi_"
All "calculation" fields or other fields that are only used internally and do not appear on any interface and are not used as a key. - prefix of "zc_"

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
_Astrid_Author Commented:
Thank you both for your amazing feedback and tips. I'm most appreciative that I found this great resource here. It's proven invaluable! Will, thank you again for such amazingly detailed feedback and for your crystal clear notes. I feel I've learned so much in such little!!!!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
FileMaker Pro

From novice to tech pro — start learning today.