I would be greatful for any users with experience of running large
databases with filemaker 7.

We have had a solution with filemaker 6 that has become virtually
unusable now the total database has got to 3 gig.

Files with over 100,000 records seem very slow and the speed seems
really to be based on total database size.

I am considering deploying the same solution in a filemaker 7/8
rewrite, but would be very greatful for some feedback from anyone using
a client/server solution for multiple operators with large databases,
to reassure me that the same problem is not going to happen again.

It seems that the solution we are running could be easily simplified by
putting all actions, letter, emails into a single todo/history table.
Will this fall over with 5 million records. i t woudl still only be 4
or 5 gig when it got to this size.

Any comments would be welcomed.

David

I doubt the problems you're seeing has anything to do with overall file
size or number of records. It more likely has to do with how your
solution was built, use of searching unstored fields, inefficient calcs,
roundabout scripting, summary fields on layouts, unnecessarily long
drop-down lists, bad interface design, etc.

In what ways do you experience slowness? What are you doing when it
seems to be going particularly slow?

I have one FM6 solution with nearly a million records in one of the
files, 500 fields in each record, with images for a good number of those
records. Yet my finds and other functionality are as zippy as when I
had just 100 records.



David wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

A simple find may be quick even with a million records but performing a
find on 3 indexed fields with only 250,000 records will take
approximately 3 seconds on a G4 whose only task was to run FM Server,
add 2 more indexed fields to the search query and you've just jumped up
to 12 seconds. I've had to build concatenated calc fields to reduce
the number of fields that were being searched to keep the database
running at acceptable speeds.
The only possible reason I can come up with for the find taking so long
is that on the individual fields a lot of records matched the search
request but looking at all the fields only about 100 records were
returned.

FP <a (AT) pottnerconsulting (DOT) ca> wrote:

FM7/8 Server has two big advantages over FM6 Server:
1. Many calcs are done server-side
2. It allows a big server-side cache.
3. True multi-field relationships can drastically reduce the # of
calculated fields you are using (which reduces file size).

I'm in the middle of converting over a large project from FM6 to FM7.
With specific exceptions, I find FM7 Server to be perhaps 5-10x faster
than FM6. FM has a set of benchmarks showing that FM8 server is
perhaps 2x as fast as FM7 server.

The main exception is that imports, and deletes, seem to be unusually
slow in FM7.



--
To send email, remove the invalid and nospams.