My approach would be slightly different I think. I would most likely create a calculation field that only returns the result if the result is greater than 0. Then, I would point my summary fields to that calculation instead of the result field. I think you will then be able to directly reference the summary fields without the need for the getsummary function.
@Matt: Thanks, that's a good idea. Can I presume that your suggestion (and Phil's) confirms my suspicion, that a GetSummary calculation field on the main layout CANNOT show the summary of a field in portal records?
@Phil: Thanks for the suggestion, but ExecuteSQL is just beyond me at this point. I saw in that post that you do describe a convoluted method of trying to achieve what ExecuteSQL can with built-in FM tools and capabilities. Hopefully I can find an alternate way of doing this that doesn't require something that sounds so complicated (and fragile?).
Solution: Change the Question
I'm going to do something similar to what Matt suggested by taking the '0' results out of the equation. Instead of having '0' represent the 'unanswered' item, I am just going to create a new field ('Answered') with a 0/1 result or just a no/yes result, and use that to filter out the unanswered items from the result score. That should take of this relatively simply.
Followup Question: Slow Summary Updating
I do have one followup question. In the existing setup, I have the summary fields for the portal records on the main layout. They update correctly and show the correct 'Total' and 'Count' summary, BUT, I have to click twice outside of the portal for the update to occur. In fact, the summary Total field will go blank while editing the portal result scores, until I click outside the portal and then click outside the portal again.
Strangely enough, the summary fields have the same behavior, even when inside the portal with the records.
Why is that and is there anything I can do differently to have the summary fields update immediately, as soon as a portal record score is changed?
Thanks to both of you for all of your help.
Sometimes you can get the same total and with much smoother updating if you replace the summary field in the child table with a calculation field in the parent table that uses an equivalent aggregate function such as Count or Sum.
Thanks a bunch Phil! That worked like a charm! So simple and clean too.
Caveat: While it does not specifically solve the original post question, it does provide a clean and simple solution to the database issue.