No idea about the slowness, but here is maybe a more straightforward
way to present your calc. I don't like nested Case statements; I'm
just not smart enough to follow them. I possibly parsed yours wrong,
but:
Case(
((Web_Print = "Print") and (PartQty ≤ 100)); Round(3 + AddPrtDays; 1);
((Web_Print = "Print") and (PartQty ≤ 1000)); Round(5 + AddPrtDays;
1);
((Web_Print = "Print") and (PartQty ≤ 5000)); Round(7 + AddPrtDays;
1);
((Web_Print = "Print") and (PartQty ≤ 10000)); Round(14 +
AddPrtDays; 1);
((Web_Print = "Print") and (PartQty ≤ 19999)); Round(17 +
AddPrtDays; 1);
((Web_Print = "Print") and (PartQty ≥ 20000)); Round(21 +
AddPrtDays; 1);
(Web_Print = "PDF"); 1;
0
)
that would be my first step in trouble shooting; break down the calc
into smaller pieces until i find the bug.
geoff
On Oct 30, 2008, at 10:40 AM, Peter Kilcoyne wrote:
Hi Folks:
I have a print production database in FMP 8.5 advanced that
schedules work as well as stores information and specifications. One
of the many calculations I use is this one called "PrintDays"
Case(Web_Print = "Print";Round(Case(PartQty ≤ 100 ;3 +AddPrtDays;
PartQty ≤ 1000;5+AddPrtDays;PartQty ≤ 5000;7+AddPrtDays;PartQty
≤ 10000;14+AddPrtDays;PartQty ≤ 19999;
17+AddPrtDays;PartQty ≥ 20000; 21+AddPrtDays);
1);Web_Print="PDF";0;1;0)
It determines the number of days that might be required for the
printing of a job based on the quantity. I can amend the number of
days by adding or subtracting days in this field "AddPrtDays" making
the actual number of days for printing more accurate.
In an attempt to "improve" the calculation I added a step at the end
that was specific to one project we do. And that step used the
operator "and" to compare two fields and then based on the
comparison modify the "AddPrtDays" filed. Well that sent the
database of 2600 plus records into a tail spin. It was stuck trying
to compare and modify that field. I even let it run over night, but
the next day it was still trying. So I forced quit, opened the one
database of the eight that comprise the complete database and did
not open the others so that I could go back to the calculation and
reset it back to the way it was; without the operator "and".
Now it runs better but is still slow on the host computer, but it is
very sluggish over a Filemaker network, to the point where the other
users have to force quite Filemaker to get out of it.
I have update the "AddPrtDays" field to force the calculation to
calculate (it is set to calculate only when necessary) but still the
database is sluggish.
Any ideas on how to improve speed?
TIA,
Peter
