I have read many posts about the pros and cons of summary calcs but have not seen much about using a Sum calculation on a table occurrence with a Cartesian join.

I understand that summary calculations will only sum for a found set. If a found set is defined as only what fits on the screen (e.g. list view), that will ultimately limit what's summed, based on your screen size. Alternatively, if a found set is the result of a find (or all records, when a find has not been performed), the number of records displayed on screen and "under the scroll" won't matter.

Question: If a find has not been performed and all records are displayed (some may require scrolling) will the summary calculation sum all the records or just the records being displayed?

Going one step further - the one aspect about summary calcs I don't like is that any calculations in the calc chain cannot be stored. So in a situation where the summary calculation results in poor performance which would be more efficient:

1) Summary calculation

2) Table occurrence with a Cartesian join and using a Sum calculation on the field in the table.

Thanks!

“a found set is defined as only what fits on the screen”

This is not the case, found sets and summary fields are not affected by the size of your screen. If you perform a Find and find a million records, your Summary Field summarizes a million Records.

calculation fields that refer to Summary, global and/or fields from a related table will all be unstored. Thus, sum ( relatedTO::field ) will also be unstored.

The most common method for getting a stored aggregate value is to use a script with a set field step to set a data field to the result of a calculation that would be unstored if used to define a calculation field. That calculation could use a summary field or your sum function via Cartesian join.