Caclulations very slow above 10 records

[Jambox Entertainment]

Hi, I am relatively new to filemaker. I wasn't sure where to post this, but since i think the calculations are causing the problem, I will post it here. I am working on databases for the recording studio I work at (we are making the transition from keeping our clients records on paper to keeping them on the computer)

The database has some basic calculations (cost=rate*hour, etc.) and some calculations take information from the previous record. The problem is, once we get over approx 10 records in one client's database, filemaker starts performing the calculations very slowly. When the necessary fields are filled out and its time for fm to calculate, it takes about a minute to do, and as there are about 5 calculations for each record, a record that should take 30 seconds to fill out now takes 5 minutes.

The only solution i can think of is to have a separate database for every 10 records, but I would really rather only have one database per customer. This is confusing me because it doesn't seem like it should be a very processor intensive task, and we're running it on a iMac G5 1.8 GHz 768 MB ram. It also runs slow on our PC

Here is the session sheet i am using (with no records): http://amchap06.googlepages.com/BlankSESSIONSHEET.fp7

And here is one with records that runs really slow and makes me force quit filemaker often: http://amchap06.googlepages.com/SessionSample.fp7

Any help or information would be greatly appreciated.

[dreamingmind]

jambox,

You will surely get more informed opinions with specific explanations, however:

Changing your calculations to number fields that auto enter a calculation improves things greatly as you can see from the attached version of your sample file.

The calculations now trigger only when a referenced field changes. This will happen for some calculations and not others as you enter data. And NO calcs will run when you navigate from record to record.

With all live calc fields as you had, everything in a record must calc as you move around.

I wasn't sure what was up with that credit field that uses getnthrecord so I didn't change that one. It looked fishy but I was too lazy to figure it out.

Regards,

Don

[IdealData]

The calcs using the GetNth record are effectively recursive so the problem will grow exponentially. I ran record 26 on an iMac Intel 2.0Ghz and it sure is slow. As the calcs are unstored then every invocation requires every record to recalculate. So record 26 has to wait until record 25 has calculated etc. Each record is also dependent on all the predecessor records too.

It ran my iMac to 99% CPU usage!!!

It's time to rethink your design.

[Jambox Entertainment]

Thank you both, i took both of your advice and it works much better now. I basically have it so all the calculations index, though i might experiment a little more with putting some of the stuff back to calculations, because sometimes the credit or balance field remains uncalculated and the sums dont add up. But my main problem is fixed, thanks again.

Also, I have another problem, in another post topic, if you feel like solving more problems: http://fmforums.com/forum/showtopic.php?tid/198258/

TimeCards got me down!

[comment]

Summary fields are much better suited for this.