They want to buy a new PC-server. Can you tell us if a dual 800 mhz (win2K)
is a lot faster than a single 800 mhz or is it not worth the price? What
about putting a second ethernet-card in it? Or is the network
connection(100MB) not the real bottlenech? We'll put 2 harddisks 10.000 rpm
in it and have orderlines running on one disk and all the rest on the other?
Is this another step in the right direction?

--
Pascal Jacob

350 fields in orderlines?  That sounds like trouble.  Why so many?  Is it
possible that some of this information belongs elsewhere or could be
condensed into multi-purpose fields?  Any information being stored more
than once?

Your orderlines database is about 6 times the size of ours (records),
growing at about 8 times the rate with 10 times the number of fields, and
could be bordering on being beyond FileMaker as it is currently designed.
Ours is about 40 MB.  How soon before yours exceeds 2 GB on it's own?

As for the slowdown, IMHO it's more likely related to design issues or
network limitations than it is to server speed.  We have a dual processor
server, but I don't have a good idea how much it improves performance
(nothing to compare it to).  I do know that it doesn't seem to be working
very hard (based upon CPU Usage monitoring), even when I do something that
"feels" slow in FileMaker.
--
Glenn Schwandt

My experience with a dual processor was that it was infact noticably faster when
using FMP v5 server/ clients and 100t.

However, I found that the dual processor server OS (NT) crashed fairly regularly
and mandated rebooting daily.  I am uncertain if the crash rate was more or less
than a single processor system (but it required fewer reboots), but it was much
more regular than the Mac OS server crash rate (which was definitely slower
serving the pages than either of the NT systems -- but the clock rate was
substantially different -- perhaps unfair comparisons).

Much like the other comment, I found that ultimate speed relied on dbase
design.  How much info was being searched regularly, how that info has been
indexed, relational structures being implemented, number of calculated fields
per record (order line).  As a matter of fact, the last issue seems to be the
biggest factor in the dbases that I have seen and/or worked with.  I improved
one structure's speed by nearly 5 fold by reducing the calculations from being
done as a calculated field and switching it to script based calculations.

Hope that helped.
All the best
{*filter*}

<SNIP>

It certainly does.

Only stored fields can be indexed.

Indexing improves the speed which which certain functions takes place, for
example, finding and sorting, but at a cost of increasing the size of the
file and the increasing the time it takes to tab between fields.  Fields
can be set to be stored or unstored, or can be set to turn indexing on
only if needed.  When in doubt, the last option is the usually the safest
bet.

Fields which are formatted as pop-up lists which reference fields rather
than a static list of values must reference fields which can be indexed.
Hence, the values in those fields must be stored.

Some fields cannot be stored (Global fields, Container fields, Summary
fields as well as Calculation fields that contain references to Global
fields, Related fields, Summary fields, or other unstored Calculations
fields).  Consequently, these fields cannot be used as value lists.

Some fields should not be stored, for example, Calculation fields which
use Status functions to reflect the changing status of many things, for
example, date, time, found count, record number, and so on.

--
Bridget Eley