Slow preview

[mf]

Why would "preview a layout" be much slower than a "browse a layout"? (seems at least 5 times, particularly for small number of records 2 to 10 even)

This is a general question. Most of the fields displayed are unstored calculations.

Thanks

[kenneth2k1]

Hi:

I notice a significant slowing of preview mode if the layouts either have a lot of graphics or large graphic files. This is especially true on Windows machines and older Macs.

Do you have any of these things?

[Vaughan]

If the layout has a sub-summary part FMP has to perform all the summary-related work to display it in preview mode (summary reports don't display in Browse mode).

[mf]

I am using Windows... and there is no summary calculations.

It did not seem to take as long before... I suspect that I am doing something wrong, recently I have made several changes to my database and I was wondering what I could have done to cause this. The changes were not to the layouts per se, but to the relationships and created new fields.

Thanks for your input.

[-Queue-]

Can you attach a clone of the troublesome file and point us to the problem layout?

[mf]

Sorry, it's not that easy to extract the problem area and put it in a form that could be meaningful to you. Sometimes, having to explain a problem takes more effort than figuring the solution ourselves...

I was hoping for some pointers, not so much for resolutions (that's what they pay me for, right?)

[mf]

Sorry, it's not that easy to extract the problem area and put it in a form that could be meaningful to you. Sometimes, having to explain a problem takes more effort than figuring the solution ourselves...

I was hoping for some pointers, not so much for resolutions. I thought that maybe I am missing something obvious.

[-Queue-]

Um, it's actually easy to zip (or stuff) and attach a clone. We only need to see the fields on the layout and refer to their definitions to narrow down the possibilities. Mind reading isn't one of our specialties.

[John Caballero]

-Queue- said:

Mind reading isn't one of our specialties.

I knew you'd say that.

[-Queue-]

Okay, okay, so Cabby's a psychic and I'm just a moron.

Anyway, my point was that if you're so eager to ask for help, you should be willing to provide the evidence to help us solve the problem, if our ouija boards are on the fritz at the time.

[kenneth2k1]

My ouija board always works for me.

I just peek and push the pointer thingy to the answer I want!

So let me see what it says, hold on...

It told me that there's something wrong with your file. There you go.

[mf]

Very funny...

Let me rephrase the question: have YOU ever experienced a difference in time of display between Browse and Preview? if so and if it mattered, how did you go about to speed up the Preview?

if not, never mind.

[kenneth2k1]

Like I said, in my experience large images and many fields (by many I mean like 250 fields) would slow it down for me.

If you have a lot of unstored calculations on the layout, then it may take a while for FileMaker to make those calcs since it will need them to print.

Please let us know what OS you have, what version of FM and all that stuff.

If you noticed the slowing after you made changes to the database, then I would suggest back-tracking and maybe changing one thing back at a time and see if it changes anything.

[mf]

Thanks for your thoughts...

We are using Windows NT 4.0 SP6, and the versions of FM vary from 5.0 to 6.0 (we have revisions where available)

You are right: we have many unstored calculations (no choice there), no image. I have re-saved the file (compressed). It does not have many records, it can vary from a dozen to a few hundreds. It is a file with nearly one hundred layouts (it is a reporting file where data gets imported, no data entry here) and nearly as many scripts. The calculations are not super-complex, but again, there is close to one hundred fields, all but a few are calculations.

Like I mentionnned before, it seems that we only recently start noticing a slower preview. I inspected the scripts closer, and tried to improve the code.

A preview may display up to 21 records (3x7, you could say "labels") in a 8.5x11 page for small layouts. In this case, I understand that it would be slower to preview than to browse. But when dealing with a larger layout (that occupies the whole page ie only one record) I would have thought that a browse and a preview would take the same amount of time. I don't have hard numbers, as to how much slower, but it is noticeable... Browsing instead of previewing these layouts is not the goal. It is just something I noticed and I was wondering what could be different.

It is not a show stopper... but something to improve if it is possible. There might not be anything to do short of rethinking the whole approach.

[BobWeaver]

Summary fields and unstored calculations that use the GetSummary function can be extremely slow even if you only have one record showing. The GetSummary function would be slow in both browse and preview mode, but summary fields would be a problem only in preview mode.

[mf]

Quick update:

The resolution of my problem was where I did not want to look... I had to revisit all the calculations (unstored) and figure out where they could be eliminated and replaced with plain data. I created scripts to update the data, I now have to rely on the application administrator and nightly updates. It will work, and it is definitely faster.