Having spent a frustrating time trying to perform a GetSummary from a related table, which was only resolved with extensive help from members of this forum, that I was informed that this function does not work outside the TO that it is present in. I can find no information to this effect anywhere including The FilemakerPro Bible, VTC, O'Reilly's The Missing Manual or Filemaker help.

It's not that the function "does not work" - it's more about the function being designed to work in a certain context.

When you have a sorted found set, the GetSummary() function returns a sub-summary value. It's the same value you would get if you placed the summary field in a sub-summary part sorted by by the breakfield.

This allows you to do calculations involving different levels of sub-summaries, for example: if you have a found set sorted by Month and by Account, you can use =

GetSummary ( sTotal ; Account ) / GetSummary ( sTotal ; Month )

to get the percentage of the account's total in the month's total.

Note that the results are different for each sorted group.

This also works across a related set. If the calculation is defined in the child table(!), and the relationship (or the portal) is sorted by the breakfield, each portal row will show the sub-summary value by the breakfield.

Defining the calculation in the parent table is meaningless, because from the parent's point of view all the groups in the related set are equal.

It's not that the function "does not work" - it's more about the function being designed to work in a certain context.

When you have a sorted found set, the GetSummary() function returns a sub-summary value. It's the same value you would get if you placed the summary field in a sub-summary part sorted by by the breakfield.

This allows you to do calculations involving different levels of sub-summaries, for example: if you have a found set sorted by Month and by Account, you can use =

GetSummary ( sTotal ; Account ) / GetSummary ( sTotal ; Month )

to get the percentage of the account's total in the month's total.

Note that the results are different for each sorted group.

This also works across a related set. If the calculation is defined in the child table(!), and the relationship (or the portal) is sorted by the breakfield, each portal row will show the sub-summary value by the breakfield.

Defining the calculation in the parent table is meaningless, because from the parent's point of view all the groups in the related set are equal.

Hi Comment,

Yes, I understand the value of being able to manipulate different summaries within this context, but that still does not stop me wishing for an easier way to bring in and manipulate summaries from other tables such as the one I was trying to achieve earlier. What could be nicer, I have a summary of the data I want to use which can be changed at will just by changing either the sort order or sort field and all I have to do to manipulate that in my current table is to say GetSummary, Wow. I can think of several instances that I could use that for right now. For that reason it is a definite "Wish List" item for me. The "Does Not Work" statement was from your quote "You cannot get data from a found set of another table." and as it was only due to you that my problem was resolved.

I have a summary of the data I want to use which can be changed at will just by changing either the sort order or sort field and all I have to do to manipulate that in my current table is to say GetSummary

I am afraid you are missing a very important point that has much wider implications than just GetSummary:

The only channel through which information can flow from one table to another is the relationship between the two tables.

The current found set or sort order in one table have no meaning in the other table. In cannot work any other way. For example, suppose you have two windows open, each showing a different found set from Table A, sorted by a different field. Which of these two should apply when working in Table B?

I am afraid you are missing a very important point that has much wider implications than just GetSummary:

The only channel through which information can flow from one table to another is the relationship between the two tables.

The current found set or sort order in one table have no meaning in the other table. In cannot work any other way. For example, suppose you have two windows open, each showing a different found set from Table A, sorted by a different field. Which of these two should apply when working in Table B?

Your depth of experience and knowledge obviously far exceeds mine but wouldn't the same apple for a sum of found records in one window and a different found set in the other window, which sum would the calc use. You know from the posts that you have already assisted me with that my experience is limited and I was sort of hoping that the script used to produce the found sets in the different tables was contiguous thereby producing the correct summary for that particular calculation at that time. Dreaming is good, especially when you have a shrink on hand to tell you that your dreams are the stuff that nightmares are made from. Thanks for the reality check.

wouldn't the same apple for a sum of found records in one window and a different found set in the other window, which sum would the calc use.

That's a good question. Why don't you try it and see for yourself?

It operates in the window in which the script was run from and therefore on the found set determined by the script, which was what I had hoped would happen with my "Wish List" GetSummary.

It has nothing to do with a script. The GetSummary() function returns different results in different contexts. Even with one window and one found set, the result of the same calculation will be different for each sorted group. For a record in group A, it will be the total of group A. For a record in group B, the total of group B. In which of these groups is a record in another table??