Jump to content
Salesforce and other SMB Solutions are coming soon. ×

calculation with related globals: performance


Recommended Posts

Hi there,


Before, I had one main file with calculations. The performance was satisfactory.

Now, I replaced some values of these calculations by globals from a related file (so the related file works as a Prefs file for the user).

This works very slowly, although it concerns small files (228Kb main file and 40KB Prefs file).

My foreign keys: in the main file a number calculation =1 matches an indexed number field =1 in the prefs file.


Example (I kept it simple):

in the first case, I had an unstored calculation e.g.


In the second case, I made this calculation =



Does this sound familiar? Does anyone have any ideas why the performance is slower? This should not be happening, should it?


Thanks in advance,



PS: sorry administrators, but I put this message by accident in the wrong category! Can you move it to Calculations and Define Fields or Portal & Relationships ? Thanks !

Link to comment
Share on other sites

Hi Sabine,

Relationships that are to be used solely to reference values in global fields operate acccording to different rules from other relationships in FileMaker Pro.


One feature of this is that they do not require that the fields on *either* side of the relationship be indexed. For all other purposes, such a relationship is invalid, but it will still work for passing global values. Interestingly, in certain circumstances, an 'invalid' relationship of this type responds more quickly when passing global values than an indexed relationship does. This is because FileMaker does not first have to pass the Ids of all the related records between the files to establish the relationship, prior to passing the global field data across.


Whether this information will prove useful in your case depends to some degree on the structure of your files (and the number of records in each etc) but in some circumstances (esp with hosted files) it can make an appreciable difference.

Link to comment
Share on other sites

Hello Ray,


thanks for this information.


As for my problem:

I tried to narrow down the problem by throwing away several fields.

First I reduced the Prefs files' record number from 20 to 1. No significant difference.

Then I replaced the related globals in the calculations by constant values. Small difference.


But I also have running total summaries. If I delete these, and KEEP the 20 records and KEEP the related globals, the other calculations are made at a normal speed. The summaries also depend on the calculations.


So I think the summaries are more likely the cause of the speed problem. It is as if the summaries are counted over and over again for the previous records, which isn't necessary when I didn't change any values in the previous records, is it?


I just had the impression first that it slowed down since the related globals.

Link to comment
Share on other sites


Yes, summary fields can be serious resource hogs. They're a 'nice to have' feature for light duty work, but they do bog down when the load builds. The combination of unstored calcs and summary fields accentuates this effect, of course.


The more conventional approach, which is generally better suited to more complex or high turnover solutions is scripted collection of summary data, which can be refreshed as and when necessary, rather than tying up the processor re-evaluating everything after any small change to the data.

Link to comment
Share on other sites

  • Create New...

Important Information

Terms of Use