Yes, be they calcs or stored data, you need indexes. One last thought: I mentioned a looping script and I'd like to take that back. I think it will be a long time until i get FileMaker 6 out of my head. 

Better would be a script trigger (on commit or field exit, whatever works best for you) on a base data entry field. It fires and populates the proper value into that second level. You have already done the calc; just copy it from that second level field definition and adapt it to push that calced value into the stored data field that takes it's place at level 2. I would change one at a time, and see how much speed each one buys me. As Steve said, the work has to be done somewhere; if you can move it to tiny increments as you enter the data rather than all  at once as you read it - bonus.

If this works you wouldn't have to change the way you work with it or worry about data not populating up your tree.

good luck,
Geoff

On May 5, 2010, at 3:55 PM, Sue wrote:

> Thanks, Geoff.
> 
> I was afraid that was the answer re: stored calculations.  Your suggestion to tackle the problem just at the second level sounds like it would be well worth some consideration.
> 
> I am definitely not excited about the option of exporting and importing data between the levels, nor do I like the look up or auto-calc option.  Too easy to end up looking at incorrect info based on old data.
> 
> I appreciate your suggestions.  Thanks again.
> 
> Sue
> 
> On May 5, 2010, at 12:25 PM, Geoff Graham wrote:
> 
>> On May 5, 2010, at 1:56 PM, Sue wrote:
>> 
>>> I am wondering what steps I could take within Filemaker to speed up the file functioning, such as possibly storing calculation results at each level (none are stored at present, which I suspect is the problem).  Is there anything I need to consider before changing all of my calculations to stored? Can I assume the fields will recalculate as necessary whenever additional data is added at the bottom level, or not?
>> 
>> That does appear to be the low-hanging fruit for you. Your second option actually changes your structure some, which you are satisfied with except for the speed issue.
>> 
>> Stored calcs that use indexable data from the current record will auto-update; Stored calcs that use data from a related record will not, if only the data in the related file has changed.
>> so from what I'm picturing of your solution, no, they will not update as necessary. I might try to change a few key fields at that 2nd level to text, number, whatever; instead of a calc, with the needed lower level data getting in there via lookup or auto-entered calc. From the description of your structure, just getting some indexes at that second level may very well give you acceptable performance again.
>> 
>> Lookups and auto-enters may not cut for you you, in which case I would brute-force it: Script getting the data from level one to level two. I picture a looping script with a go to related record and a few variables. If I had to export a summary temp file from level one, then import that into level two, well I would hate myself a little, but I'd eventually get to sleep that night. :)
>> 
>> Geoff