Image files on same Server as FMSA. How to reference?

[keysersoze]

Hi,

I am hoping someone can help me out. We are running FMSA 9 on a Windows 2003 platform. Our database includes a container field which we would like to hold images. We would like the images in the field to be file references only, to save space and performance. We wish to place the original images themselves, in a folder on the same server. How do we get the image to appear in the container field in the database?

I think this has to do with the filepaths, but I am not sure. Any advice would be most appreciated.

Thanks!!

[IdealData]

This is a well trodden path, with many references on this board, but no absolute answer.

You must network share the folder where you are storing the images so that users can specify the image when creating/editing records. This also means that the user will need to mount the network share.

The problem occurs when another user, with a dissimilar system setup tries to access the same record at a later time. The mounted path may not be the same as the original (especially with Mac/Win) so FMP cannot resolve the path and your image can't be found. The network share must also already be mounted!

You could look at mapping network drives under the same scheme for every one, but it is difficult to maintain.

[keysersoze]

IdealData,

Thanks much for your quick reply. I feared this was the case.

It seemed like it *should* be easy, because the images reside on the same physical server as the database, but I can see how the paths would create problems, especially when moving from one client machine to another.

As a workaround, is there a way to reference a web-based image? For instance, if we hosted the images on a web server, could we reference them somehow that way, by using the url address? I am a novice, please bear with me.

Many thanks again!!

[Vaughan]

It's not best practice to have a shared volume on the FileMaker Server box: file sharing and FMS are both disk and network intensive applications, and they'll compete for resources and lower performance.

The simplest and most robust is to put the graphics in container fields in a "preferences" table an keep it all within the database. FMP is pretty efficient at moving data around the network..

[Steven H. Blackwell]

What Vaughan said.

Steven

[IdealData]

Just in case I appear to have confused the issue, I only answered the question - my preference is also to store the images in the database.

[CurlyD777]

FMP is pretty efficient at moving data around the network..

I am also starting to look into a image sharing feature for our database. We're an advertising company and need to store our client's many PDF's for particilar sales in this

Currently, we have 10000+ pdf's that are typcially 3-10 mb each. (Our practice is to never delete a revised PDF for each client so our PDF collection grows very fast)

I would estimate our PDF archive is currenlty about 1 tb. Each file is stored by client name and then by their sale/job. You can imagine how time consuming it is to find a particular client's pdf using our current file sharing volume.

I would like to store these PDF's in the database not as references but as actual embedded files, since I could imagine how hard it would be to rebuild referenced paths if a volume or path name gets changed.

Long story short, prior to starting this project, I'm concerned about overloading filemaker with a libary of 1TB, and trying to navigate around files 3-10 mb each.

I would appreciate it if someone could let me know if I'm overloading filemaker with storing files this large into a single database?

(We are using fileMaker server 9.0 advanced on an intel based xServe with 10.5, so I think we have the hardware side covered.)

[Vaughan]

Thousands of pdf files are a different matter.

I'd suggest leaving them on the file server, and creating a FMP database that uses meta-data to help locate the documents -- a catalogue, as it were. The documents would be stored as a reference, not in container fields. The files could be opened directly from the database.

One of the biggest challenges will be linking to the files; I hope your naming convention was simple and rigorously adhered to, otherwise there's going to be a lot of hand coding (or file renaming) to do.

[CurlyD777]

Thanks for the update, we'll stick with the reference only method. Luckily, since it already was a challenge to sort and find files, we've made a very strick naiming policy to store these. In other words, each file is stored and named in the same file / folder structure.

You've mentioned I should create a database with meta-data to help find these files, would you mind elaborating on this concept?

thanks