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
