FMS Images do not display on client machines

[Christensen Design]

I have a FM db hosted by FMS v10/WinServer 2003. I am having difficulties getting linked images (i.e container fields that store only a file reference) to display correctly on client machines.

The clients are running either FMv9 or v10. The image files (mostly .jpeg's) are stored in a shared folder that is located on a volume of the same Win2003 server that is running FMSv10. The shared folder is mounted on the desktop of each client machine. Users can open the shared folder at the desktop level and browse and edit the images with no problem. However.. within the FM client app, the images do not appear in the container field. Instead, the fields only show the pathname to the file. The container fields do not show "The file cannot be found:" in front of the path which indicates to me that the FM client does know the file it there; it is just not displaying an image preview. Also.. using the TROI File plugin I can issue a command to 'reveal' the file at the desktop using the same path name, and that works correctly. TROI file also returns TRUE for the file 'exists' command. So the files are there.

Is there some limitation with FM client's displaying images from referenced files that are loaded across a network? If so, how do I get around this for printing purposes? We are trying to print a catalog from FM using these referenced images.

Thanks much for any help. John

Edited February 11, 2009 by Guest

[Steven H. Blackwell]

The image files (mostly .jpeg's) are stored in a shared folder that is located on a volume of the same Win2003 server that is running FMSv10.

That is not an optimal practice or a Best practice for FileMaker Server.

Why didn't you store the files in the container fields themselves?

Steven

[Christensen Design]

Well.. for many reasons:

1) concern over the data file size which can slow searches. The image data is only about 250MB at the moment, but will likely grow to 1-2GB. Is this not a big problem with current FM and current hardware?

2) my client likes to be able to browse images at the desktop level so he can do searches to pull large groups of similar images together. The files are named (via FM) with a structured system. He will do things like search for all files that contain 'STN' to pull up images of all Stanley tools. He can then quickly drag drop to various volumes, a CD, etc. Obviously all Desktop functionality could be recreated in FM, but at a cost.

3) integration with other software. With the files stored at the desktop, it's possible to have other apps access the images (i.e. a web server, a catalog printing app, Photoshop, etc) without having to have FM export/sync those images to a folder somewhere.

4) concern over the loss due to possible data corruption. If one file (the FM db doc with images) gets corrupted, I could lose 5000-10000 images; whereas if the images are stored outside the db, it is much harder to lose them all due to corruption.

Basically these are all the same reasons that most media management tools (iTunes, iPhoto, Cumulus, ect) store their media files outside of the database of meta data.

So.. if I do have to store the images in the FM DB (and give up desktop access to the files), my instinct would be to put all images in a separate table so that the image data is separated from the text data. There would then be a one-to-one relationship between Parts and Images (this is a Parts/Catalog system). But.. then my question is, is there any advantage to putting that Images table in a totally separate FM database file? Or is the separate table within the main FM db good enough?

Thanks much. John

Edited February 12, 2009 by Guest

[bcooney]

I agree it's best to ref the images. However, note Steven's advice that FMS is best running on a dedicated box. Perhaps, this has something to do with your display problems.

If you're storing images as refs, there is no need for a separate file. But, yes, if you store as containers, depending on file size, it is suggested to separate the image file so that backups will be easier to manage.

If you're seeing the path, is it possible you have some sort of calc field operating on the container that's resulting in text? What happens if you Insert an image from a file on your desktop?

[Steven H. Blackwell]

If you store the pictures in a file, I would use a separate file as you describe with a one to one relationship. You get better file management that way. A 1 GB file is not all that big.

In theory you should be able to store a reference and have it access via a mounted volume. However, remember that the path may be different from each workstation. Would it work better to have these on a FTP server can call them that way?

Steven

[Christensen Design]

I know for sure that the calculated path is valid. And yes, I have also taken into account the fact that the path could be different on different machines. I have a utility that executes the TROI File 'Exists' command on each path. It returns TRUE for all 2000+ records indicating that the path to the Images folder is valid. FM even indicates that the files are there in that the container field displays the path name without adding the words "Error:.." in front (which is what it does whenever a path is invalid). So the images are there, but the container field shows the path rather than the image. If I launch stand-alone on the same client machine with the same images folder and no code changes, the container field correctly shows the image rather than the path.

The problem with ftp is that printing becomes a mess. This DB is a catalog generation system. So when we print one of the catalog layouts, FM needs to send the full-res image to the printer. Having to execute an ftp command for each image on a printed page could be problematic.

Also.. I don't think this has anything to do with the image volume being attached to the FMServer. I am well aware that for optimal performance one should not have filesharing turned on on the server. But.. aside from performance concerns, this arrangement should still work (at least for test). Just for hoots tonight I will move the images to a third computer just to be sure and report back.

Thanks much for all the suggestions. Any ideas are welcome. John

Edited February 13, 2009 by Guest

[mr_vodka]

If you have Troi file then why bother with a container at all?

[Christensen Design]

If you have Troi file then why bother with a container at all?

Well... because the only way to print/display an image on a filemaker layout is to put it into a container. right?

Edited February 13, 2009 by Guest

[IdealData]

I know for sure that the calculated path is valid. And yes, I have also taken into account the fact that the path could be different on different machines.

Could you post the calculation? And an example of the result?

[mr_vodka]

I believe that I misunderstood you. I thought you were looking to print the orig image and you were storing the references in FileMaker.

And you should be able to use other means to display an image such as the webviewer.