Is there a way to extract the count from a summary field in a portal? Is it just better to use an ExecuteSQL instead?
Is this perhaps a filtered portal?
If the portal is unfiltered, you can just refer to the summary field from the related table and you get the same value that you see. If a script, calculation field or such is set up to do this for a filtered portal, the summary field's value will ignore the filtering and summarize all related records instead of just those that pass the filter.
ExecuteSQL is then definitely an option as you can usually reproduce the filter logic in your SQL query to get the needed total for just the same records. But it's not your only option. Sometimes you can redesign the relationship to match to the correct records without filtering. GetLayoutObjectAttribute can access the value of the summary field object sitting inside that filtered portal--though this makes your calculation brittle, a trivial layout change that alters an object name or removes the summary field from the layout breaks the calculation.
what do you mean by extracting the count from a field ?
A summary field is some kind of special field in that it have a contents only when it is added to a layout and that the records are sorted properly.
What would you like to achieve ?
Yes, sorry, it is a FILTERED portal. I have test responses and I am filtering to just the number of correct answers in that section for that specific test taker. I want to take that result, found in that specific layout, and then use the number in calculating other percentages or scores that will be shown in that same layout. I can have the filtered portals hidden to view. I have 7 sections, and depending on the test taken, different calculations of the resulting summary count fields will be utilized.
Since I only need the calculations of the Summary count number for the one layout, can I use GetLayoutObjectAttribute? It seems like that may be the easiest. I am also trying ExecuteSQL as well, just that not all of the portal filters being used are from the same table (they are from 2 related tables) so with my novice understanding of ExecuteSQL (still), it is current;y still a work in progress.
My preference would be either a direct relationship that uses additional match fields instead of a portal filter to get to the right data (This is not always possible) or ExecuteSQL.
just that not all of the portal filters being used are from the same table (they are from 2 related tables)
That usually does require a more sophisticated query. Research SQL joins in the relevant materials as you can link to tables in a "Join" in your query, then specify WHERE clause criteria for both to get your answer.
Ended up getting the ExecuteSQL to function. You are definitely right, it at least simplifies a bit more than trying to pull an attribute from a filtered portal.
Retrieving data ...