Hi all:

I have a table,

It sounds like you're using a normal (or calculation) field in the subsummary instead of a summary field.

THIS POST WAS A REPLY TO MY OWN AS A FOLLOW-UP QUESTION, AND NOT AN ANSWER TO ANOTHER POSTER.

Have been trying various combinations of base-tables and sorts, and I get the farthest when I use 'Invoices' as the base table, but still cannot get the sub-summary to work. Is it absolutely necessary for me to have to do some calculations in the creation of the Invoices themselves that will carry a summary amount from the 'Trips' table into the 'Invoices' table?

I REALLY want to avoid that if possible.

Thanks

No, the field is a summary field inside the 'Trips' table. And it DOES summarize correctly on a similar layout based on the 'Trips' table.

But once I try to do something like it off of the 'Invoices' table, it wonks out. MUST you base a layout off of the table upon which you want a summary field to act? Or should the relationships allow summary fields to work in layouts based off different tables?

Thanks

Ahh, summary fields are table-dependent. You can't use a summary field for Trips in Invoices and expect to get the correct result. You would have to use a calculated Sum(relationship::field) for that.

AH - was beginning to see that. Can you explain more about the calculated sum you mention?

Sure. You would create a calculation field in Invoices that uses the relationship to Trips and the field that is totalled in the Trips' summary field, not the summary field itself. So it would look something like Sum(Trips::datafield). Since each record in a particular subsummary should contain the same TripID (unless this is an incorrect assumption), it will give the same result for all of them and can therefore be used in a subsummary part accurately.

That makes a lot of sense, I am going to give it a try.

Thanks for the help, Queue.