Any slowness is most likely caused by FMP having to evaluate some value as part of working out what records to display. Most commonly this is caused by an unstored calc at the other end of a relationship.
Suggest you start by showing / writing out exactly what sort of fields are involved in your relationships.
Screen shots pasted into Omnigraffle is a good way of debugging these sorts of things.
Any which hold values which are not set in concrete require reviewing and possibly changing.
One method is to duplicate any such fields and change the original fields to "concrete" but looking up from the copies
Then use a self relationship to run the lookup.
Alternatively you may find you can use auto enter in the key fields but with the don't evaluate checkbox unchecked so that they do evaluate when something the auto enter calc they contain changes in value.
A common technique to make this sort of thing update is a "tickler" - an additional cartesian predicate in the relationship with a value that is guaranteed to change hence forcing the relationship to re-evaluate.
The point here is that having a concrete field with an auto-enter on the other end works but any form of unstored calc doesn't.
Sorry this is fairly general - if you give the necessary info then I am sure someone will help.
are the Months complete calendar months from the 1st of the month to the last day in the month?
IF SO: there is a much faster way to code the relationships avoiding the date comparisons with greater thean and less then, and it is this:
create a number field in each table representing the year and month numerically, YYYYMM and make a relationship with EQUALS - this is hundreds of times faster
+Field Months::YYYYMM = Year( Months::DateStart ) *100 + Month( Months::DateStart )
+Field ContractsPerMonth::Signed_Date_YYYYMM = Year( ContractsPerMonth::Signed_Date ) *100 + Month( ContractsPerMonth::Signed_Date )
then change the relationship criteria:
Months::YYYYMM = ContractsPerMonth::Signed_Date_YYYYMM
AND Months::zz_Sold = ContractsPerMonth::Status (zz_Sold is a literal "Sold")
Does that help?
Is the Field Conf_Grand Total
a) a stored number? or
b) an unstored calculation or sum?
If b) is the answer, then yes it will be slow because you are dynamically summing a dynamic sum.
Are you sure about your data sources of your TOs. It happened to me once to have a duplicate one that absolutely killed performance.
That said, > < are much slower