FM7 container fields are VERY slow to display

[pstys]

I am connecting remotely to a multiuser FileMaker Pro 7 database

hosted on a Mac OS X machine with container fields where I want to

store large images files. Problem is, even navigating to a record

with a large file in a container field takes a long time to just

display the file's icon: minutes for a 100 MB file!!! (I'm not talking

about importing/exporting the file from the field, just navigating to

a record with such a file previously imported).

Reading FileMaker's impressive claims that v7 can support up to a 8TB

database made me upgrade, but if FM insists on loading the entire

field contents each time a user navigates to a record just to display

a file's name and icon (if that's what it's doing, I can only assume),

it becomes useless if it's this slow.

Am i doing something wrong? Is there a way to make this usable? If

100 MB takes several minutes I can't imagine how long it would take to

navigate through an 8TB DB, let alone export this data!!!

Thanks for any pointers,

Peter Stys

[Baloo]

Have the container field store the path to the file instead of the file itself. I

[pstys]

Sure, storing by reference is fast, but my goal is to store all the files INSIDE the single DB as a convenient package, rather than still have to deal with 100s or 1000s of files scattered around my drive that could get moved or deleted.

Peter.

[cmcd]

I am having exactly the same problem with filemaker 7. I'm also creating a library of large images and am concern about how slow it is to navigate through especially using remote access. Would also be grateful if anyone has any suggestions .Like peter I need to store my images in the database and not just a reference to them,

Thanks Colleen,

[The Shadow]

If you don't show the full-size image on your main layout, it should not be downloaded to the client even as the records are browsed. You can have another layout (maybe setup on a tab) that contains the full image to allow it to be manipulated.

[cmcd]

Thanks Shadow, That does seem to be the best idea .

[pstys]

You'd think it shouldn't all be downloaded if you dont show the full image, but it appears to be. In my case, all I am displaying is the icon and filename of the file imported into the container field, which takes several minutes (yes MINUTES!!!) just to display the filename of a 100 MB file from a remote DB on our LAN (not even across the net).

Looking at Activity Monitor while one waits reveals only a few hundred kBytes/sec network traffic, so there is a serious problem. In fairness, my "server" is an older 350 MHz G3 which we are upgrading, but still! FM should not be loading the whole binary object just to display the name and icon.

Such performance is a complete show stopper and makes FM7 useless for storing large binary objects. who cares about an 8TB limit when you wait minutes for a mere 100 MB?

We are in the process of installing a G5 XServe, but even if we get a 10-fold performance increase (which is what I expect at best), that still means >10 sec to navigate from record to record, equally unusable,

Any more comments or workarounds from anyone on this?

Peter.

[bruceR]

Is this a converted file or start-from-scratch FM7 file? Do you understand file referrences?

[pstys]

Turns out it's a converted FM6 file, but that makes no difference. Try it yourself. Create a blank DB with a single container field on your local drive (forget about hosting over a LAN even). Insert a 500 MB file (and, yes, I know the difference between a copied file and a stored pointer to it). Time to just open the DB and display the file icon/name in the container field on my dual 2GHz G5: 25 seconds.

Navigating through such a DB would be all but impossible.

Clearly there is a serious design flaw with FMP7 in that it insists on loading the entire object just to display it's filename.

Peter.

[kraftyman]

yes, FMP seems to load the OLE object fully, but it perhapsonly when it is in an editable field.

try this:

go to field behaviour and uncheck "enable field to be entered"

this may speed things up considerably ( it does for images)

You may want to have a data input and a separate data browsing layout with scripted buttons

[pstys]

I tried to uncheck the "Enable fld to be entered" but this made no difference. 30+ seconds just to navigate to a record with 500MB file in a container field (local drive, twin 2GHz G5). Very disappointing.

I reported this to FileMaker (http://www.filemaker.com/company/product_problems.html) and other readers may want to reinforce this if it bothers you as much as it does me. Maybe 7.03 will see a fix. I see no other way around this show stopper.

Peter.

[graceline]

I would be interested in hearing how you solve your problem of container fields are VERY slow to display...

Currently in process of build of very large DB having big use of containers and scripted buttons.. etc..

Also...

Looking for a FM7 solution / way ( scripts for scripted buttons probably) to have 10 buttons related directly to 10 container fields in a table.

When each button is pushed, the file content in each container containing movie (.mov) and (AVI) files

will be displayed in one single disply area on the screen.

So I have one viewing area (a temp container)

that will show content of each of the other 10 container files when the relative button is pushed.

Much like the function you would see in XP explorer mode... that is by clicking on a file you can view a thumbnail (picture) of the content of the file highlighted. Only one view box that can show contents of mulitple files.. How do you do that using Filemaker 7 container files???

[Kurt Knippel]

There are 2 options to use...one is to store the images as references (which you said that you do not want to do)...the other is to have 2 physical files...one stores all the information (path, name, description, thumbnail, etc) and the other stores only the large images. They are join in a one-one relationship.

What happens is that you end up with 1 file that is very small and fast and which is mostly what your users interract with...and another file that is big and slow...but your users interract with it less often.

This way the only time the actual image file is called is when you actually want to show one of the large images...and generally you will only be looking at one at a time...a simple goto related record and only that information is pulled down to the client.