SLOW performance - on a new Mac

[Danny Joe]

I've got a layout with about 130 calculation fields on it (mostly numeriical) which involve both related fields (from only 1 other database) and each other. I'm getting up to 15 second delays every time I do anything (change record, enter data into a field, run a simple script) from this layout. The computer has over 500MB of ram, it's a 2004 G4 iMac. This thing can handle 3D real-time graphics but not filemaker calculations? Seems like something must be wrong.

A while ago, the related database had its name changed, could this have affected the performance?

Anybody got any ideas?

Thanks,

Dan

[stanley]

Dan:

You say "the related database had its name changed." Was this done with the Developer Tool? Also, was this when the slowdown became apparent?

Also, is your layout showing all of your 130 calc fields? Unstored calculation fields cause all kinds of delays & should only be displayed if you really need to see the info.

-Stanley

[Danny Joe]

Hi Stanley, thanks for the reply. The name was changed in finder, not with the Developer Tool, for purposes of orginization. I wasn't the one working on the file at the time, so.. maybe this is when the slowdown became apparent. I've since added even more calculation fields, and the slowdown is worse.

I added the bit about name changes becuase when it happened, FM had to ask the user to re-locate the related databases in finder. Maybe it searches some kind of history of where the file has been, and what it has been named with every calculation? If correctable, that would be a relief, but it seems unlikely. Shot in the dark.

Regarding the necessity of viewing all 130 calc fields at once:

Basically the calculations reveal the flow of royalties to producers licensors etc for an independent record label, (the calculations hash out terms of up to 11 contracts per record, which is why there are so many - and if you know anything about the music industry, you know these contracts are not straightforward) and it is important that with every transaction entry we are able to see that the money gets to the right people. I've put the "chart" on its own layout, for ease of browsing records (using the other layouts), but unfortunatelly the chart layout must be viewed at least one time per entry. (at least while the database is young and yet unproven).

"Unstored calculation fields cause all kinds of delays"

I wish I could store them!

...still seems like 15 seconds is too long, no? I feel like I'm missing something big, like driving with the parking brake.

Dan

[stanley]

Dan:

You can look at the calc fields in the Define Fields dialog and see if they're still pointing right. They should all have been corrected just fine.

I used to be a tour manager for a band, so I know all about the complexities of the music industry and its contracts. In which case, I understand how convoluted some of your work probably is. However, you may want to look into some alternate ways of doing things.

For example. You might want to try building your db without the calculations in calc fields, but rather within scripts. The drawback is that you don't see your calculations done as you enter data. The positive is that once the data is entered, the recalculations no longer apply, and viewing would be much faster. In such a case, you could have all of your data entry fields be the same as they are now, but then you could have a "process data" (or whatever) button, attached to which would be a script which contains all of your calculation formulae, which would then dump the results into standard number (and/or text) fields.

You might also consider using the developer tool to run through your calculations & fix them - by which I mean, make a duplicate of your databases & then use the dev tool to change the names of the files. Perhaps this will correct whatever may have gone wrong when the file's name was changed in the finder.

-Stanley

[Danny Joe]

thanks for the suggestions stanley!

tour manager eh? how long were you able to keep that going?

anyway, I would probably have taken your advice and re-done the whole database with scripts, but I just upgraded to FMP 7 developer, and it runs very smoothly now.

Dan