My, have I messed up somewhere.

I have a database taking input in one particular form, and a script for
extracting the data and putting it into another.

Which works fine, btw, now that I've learnt to get around the server
lag (which was *really* screwing things up) and that's not the problem.

When I started it, it worked fine and dandy, racing through the record.
Fine.

Several thousand records later, it... crawls.

So I've pared everything down, cloned the databases on the desktop,
created dummy records, and added creation time.

The first hundred took five minutes, all in all. (Nobody said it was a
fast machine)

The next two hundred took seventeen minutes.

I beefed up the database to contain 4700 records, marked a hundred for
transfer and...

broke off after record #72.

At which point the transfer process had taken fifteen minutes.

- Is it normal for operations - set global field, new record, set
field, (a couple of lookup fields thrown in for good measure) to slow
down so drastically when you get to what seems like a moderate amount
of records?

Or rather, are there any processes you can think of that take more and
more time the bigger the database gets? The source contains a summary
field - could that be the culprit somehow?

It's part of a database/procedure that I'm going to review in detail
anyway, but it would be a help to know where to start looking for the
problem.

Many thanks,
Catja

Perhaps some of the fields in the target table are indexed and have
multiple layers of calcs based on it? Or they trigger many lookups.
Seeing your script would help to see what technique you are using for
moving the info from one table to another. And what version of
FileMaker are you using?

But let's talk about the server lag. Server lag is not normal. How are
you opening the files? When you say "server" do you mean a machine
where you have FileMaker and other shared files sitting? Or are you
actually running the FileMaker Server application on a machine dedicated
as a FileMaker server? And if you're in FM7/8, what does your defined
file reference look like?



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

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

In article <11kd2u135d8jh43 (AT) corp (DOT) supernews.com>,
howard (AT) antispahm (DOT) fmprosolutions.com says...
Actually I've seen Filemaker 7 bog down on what appear to be very simple
auto-enter/lookup via relationships... 30+ seconds PER record, for a
dead simple lookup.

1) Get rid of the lookup fields and do them as set-field operations.

2) If a setfield depends on a relationship that operates on a field set
by a previous setfield insert a 'commit records' between them.

Let me know if this helps.

I agree with Harry, for most operations there should be no real "server
lag".

It *does* seem to be normal-ish. Fortunately in my experience its also
always been resolveable.

Only if it needs to evaluate it. Start by making sure this field (and
any other unduly complicated calcs) aren't referenced by anything, and
isn't on any of the layouts being used by the script.

If you don't have filemaker 8 advanced (ideally) or fm 7 developer, its
worth the investment for the script debugging. You can step through and
see exactly which steps are taking "too long" (and get significant hints
as to what the problem might be)

-regards,
Dave

Cache size? Critical. Set it as large as possible. I've found that
FM7 will grind to a halt if you are doing a large operation if one or
more field indexes is larger than the cache size.

Also, "flush cache when idle" behaves poorly -- in my testing, it
actually flushes in the middle of looping scripts. Set it to the
higest value you can (but keep in mind that if your computer crashes,
you've lost that much more work).


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