Best practice for a fmp 9 database with a lot of pictures

[Bill_misc_IT]

I have a database of operator instructions that I use at my company. The database is approaching 85 MB due to the number of pictures that are stored in it. What is the best practice for a databse with a lot of pictures? I know I can store the pictures as a file reference, rather that the database itself. Is this the best method? I read a post elsewhere that mentioned creating a related databse file that stores the files. I'm not sure how big is too big, but I'm going to be adding more pictures soon and figured I address the issue before it becomes a serious problem.

Thanks

[Vaughan]

"The database is approaching 85 MB due to the number of pictures that are stored in it."

Only start worrying when it gets close to the file limit, which is 4 TB (ie, 4,000 GB).

I don't think the file size itself is going to cause any performance issues. The main problem is always moving large images around through the network, and that applies equally whether the database has 1 or 1,000 images in it.

[Rothko]

Can I pick this up again -

I was thinking along those lines too, whether it might be useful to store images in a separate, external file.

Well the benefits would be that if I don't want to open or look at the images, the rest of the database would presumably load a lot quicker. (The database is to be hosted by FM Server, and accessed locally and remotely by FM and IWP clients).

Also, I'm thinking that if the database file ever needs to be edited, and emailed back and forth, the file would remain relatively small (the huge container file could remain where it is).

Or am I wrong here? Obviously a big 'con' is to have to deal with two files instead of one, which is a lot more inconvenient.

very grateful for your thoughts -

Christian

[Rothko]

Found something about this in the meantime: Fenton recommends storing images in a secondary, related file.

I don't really see why having a lot of images should slow a database to a crawl. If fully embedded (not inserted or imported "As reference only"), the big images should NOT be in the data file, where you'd be searching, etc.. They should in their own simple related file. They should only be viewable in the data file on a Form view layout, as a related field. That way your other data is not held hostage by big images.

My solution should then ideally store thumbnails in the main data file, with higher-res images in a related file.

The thumbnails (like 128x128) could be embedded in the data file. Or they could be files in a folder, also stored as reference only (which is the way web pages are done).

Look at the FileMaker Help. Look at the Import Folder command. It can create 128 thumbs on-the-fly, embed them, and import the image as reference only, and the file path, and the name, all at the same time, including nested folders if desired. This was added in FileMaker 6.

What I can find about this in the FM Help and FM Scripts Reference seems only to apply to the process of importing whole records. In my case I'd ideally have the user generate a new record, enter some text and then hit a button to add an image.

Does someone have an example of a script that would do something like that?

Thanks.

[Fenton]

Is this for Mac-only? Because, if so, and the record is already created, it would not be very complex to do it with a combo of AppleScript and FileMaker. Let AppleScript choose the file.

AppleScript:

Choose file

Use Image Events to create a thumbnail file for above (examples available)

Set the paths to global field(s) in FileMaker

Call a FileMaker script:

FileMaker calculations convert paths to FileMaker syntax

Go to thumbnail's table & layout

Insert thumbnail (using FileMaker path, in script Variable)

Go to related big image's table & layout

Insert big image (using FileMaker path)

Set parent ID into foreign key

[Rothko]

Hi Fenton,

I was hoping you'd see this. There are quite a few posts by you on this subject.

No, everything has to work cross-platform. Which rules out Applescript (a shame); which rules out the thumbnail in main file/full res image in related file idea (I guess).

[Fenton]

It could be done on Windows also, but you'd need a plug-in (or command-line, which I don't know much on Windows). There are several plug-ins, at various price levels, including free:

http://mooplug.com/

(I've not tried this one, but it seems to have the basics of file manipulation. I does not have thumbnail creation, which Troi File and others have.)

Even without thumbnail creation in the plug-in, you could still do it, by using the Import Folder command, letting FileMaker create a 128x128 thumbnail.

The problem with using Import Folder for a single file choice is that you only want that one file in the folder. So move the file chosen to a dedicated folder, Import Folder, then move it back to its original location. You could alternatively copy the original to the folder, Import Folder, then delete it, but move is faster than copy for large files.

If you're willing to import both the large image and the thumbnail into the same file, then one import would be sufficient. Otherwise two. I don't really see that keeping the thumbnail in a related file would really slow things down all the much, since containers are not indexed fields. It would be worth a try, as it simplifies the process.