All of a sudden, I feel like a looped script is taking way too long. The loop works on a layout without graphics, and simply sets one of the fields with specific text and moves on. (No if statements or complicated calcs!) There are 4,000 records, and it's now taking about a minute to process every 40 records.

What could be going wrong here?

It's hard to say what it could be without seeing it. Any step which accesses a large set of records, incl. relational access, would increase with the number of records; many such steps would cause a geometric increase in time.

One simple tip for Loops is to switch to Form view; many times faster. Switch back to List view if needed at the end. Freeze Window at the top also helps, but Form view is the key. It has to do with the little slider in List view.

There are no relational fields or calculations in the layout, but there are over 4,000 records (never had that problem before with even more records).

And I am in Form view.

Script reads something like this:

Go to First Record

Loop

Set Field -- Contacts::Callsheet, "Chris"

Go to Next Record, exit after last

End Loop

Would it help to do maintenance on the file? Or will I continue to have this problem regardless?

Just realized that I did have a relational field in the layout. And it is working a little faster now -- though still not quite at the speed I would expect.

I just timed my new progress (without the relational field) -- I'm processing about 44 records a minute now. Very frustrating!!

If your script is as simple as you have indicated and you are setting one field to one explicit (or even calculated) value throughout the found set then Replace Field Contents might be quicker.

Set Field -- Contacts::Callsheet, "Chris"

In the same file or split in two???

Another thing that definately work faster is to gather the ID's of the 4000 records and put them as return delimited key into the related record, and let the field Contacts::Callsheet be shown unstored over the relation.

Take a look at:

http://www.filemakerpros.com/GetNthRecordTAIL.zip

--sd

Are any of the fields aggregates, summaries, or some combination of the two?

Can you post the file to see if it runs just as slowly on others' computers?

No fields are aggregates or summaries, and unfortunately I can't post the file.

What TO is the layout set to? You might have a context problem.

I'm not sure what you mean...the layout is accessing one of the primary tables of the database. BTW, I've been performing other, more complicated looped calculations on some of the other tables in the database, and it's been going significantly faster. So...it must have something to do with the table/layout -- but I'm not sure why.

Hi Steve,

Vaughan is talking about verifying that your layout (Layout > Layout Setup > Show Records From) points to the same table occurrence as the Set Field[] script-step. You don't HAVE to be on an associated layout with associated fields but speed is certainly affected because FM performs all scripts from the point of view of the layout. So if you have two table occurrences of that table and you are on a layout of one but setting the field of another, it will be slower.

For instance, I have 20 LineItems table occurrences which are all related to Contacts (when in Contacts, all those TOs are available). But some are direct connections and some are round-about filtered connections. Speed varies greatly when I choose the wrong one (been there, done that). You mention primary table but in 7/8 there is really no such thing. Tables are never accessed - only various table occurrences of them. So in 7/8, you can get to Los Angeles from New York via a direct route or by going around the world and FM will happily oblige. I would check and be sure they are your direct routes.

Also, have you added any Auto-Enter calcs or Lookups recently in which your Set Field[] might be re-evaluating? Just some thoughts ...

LaRetta

Two suggestions.

1. Freeze window before the loop? This will prevent the screen from updating on each record.

2. Use a "Replace Field Contents" script step, if all you are doing is replacing a field value in a found set. It's way faster than a looping script.

You owe us an explanation why you've chosen to denormalize from 2NF ...I mean you had it comming by doing so, so you could probably gain some speed by turning indexing to either "none" or "minimal" since the purpose must be to gain snappier renderings of the pages - otherwise isn't it justified!

--sd