Well nesting it a _little_ bit can save some typing and make it look
even simpler:
Case ( Web_Print = "Print" ;
Case (
PartQty ≤ 100 ; Round ( 3 + AddPrtDays; 1 ) ;
PartQty ≤ 1000 ; Round ( 5 + AddPrtDays; 1 ) ;
PartQty ≤ 5000 ; Round ( 7 + AddPrtDays; 1 ) ;
PartQty ≤ 10000 ; Round ( 14 + AddPrtDays; 1 ) ;
PartQty ≤ 19999 ; Round ( 17 + AddPrtDays; 1 ) ;
PartQty ≥ 20000 ; Round ( 21 + AddPrtDays; 1 )
)
Web_Print = "PDF" ; 1
)
On Oct 30, 2008, at 11:31 AM, Geoff Graham wrote:
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
--
Jonathan Fletcher
[EMAIL PROTECTED]
Project Foreman
NewMedia Construction Co.
