If I had to guess, I would say you have a broken relationship, and/or
have more than one copy of the file on the same HD.
On Oct 31, 2008, at 10:13 AM, Peter Kilcoyne wrote:
Thanks Lee and the others that replied, I did make this calc change,
but it doesn't solve the problem.
Of the eight databases one "can't be found" when opening the main
database. I locate it where it always is and open it and all seems
fine. After I go to that database and return to the main one it says
it can't find the main one, so I locate it and open it—again all
seems to be fine, but it isn't really.
While it was "updating" the original calc I had to force quit
because it seemed frozen. Is it possible that forcing quit corrupted
the database? And if so are there suggestions how to fix it?
Peter
On Oct 30, 2008, at 1:53 PM, Lee Smith wrote:
Maybe a Let Function might help speed things up
Let ( [
NoPrtDays = Case ( PartQty ≤ 100 ; 3 ; PartQty ≤ 1000 ;
5 ; PartQty ≤ 5000; 7; PartQty ≤ 10000 ; 14; PartQty ≤
19999; 17; PartQty ≥ 20000 ; 21 ) ] ;
Case ( Web_Print = "Print"; NoPrtDays + AddPrtDays; 1 ))
HTH
Lee
On Oct 30, 2008, at 7: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
