I want to store only a reference to a photo in a container field to reduce the size of my database file.

Q1. If the photo is stored only as a reference, does this affect speed of navigating between records & layouts ?

Q2. Using FM Server does the folder containing photos need to be in a specific directory on the server e.g. ..../data?

Hope someone can help.

1) Depends on the location of the image

2) No -- but the images would have to be somewhere all users can access it i.e. serverimages

However... I recommend you set up a "settings" table where you store the location of the images i.e. "serverimages" and then on startup launch a script that sets a global that you can then use in your calculations. Then if you ever have to move your images, all you have to do is change the value in the field in the settings table .

1. I'm interested in the speed of access to LAN clients and Web clients. Images folder on server.

2. Sounds like a good idea. Help me here..

First

Settings table, global field, text, contains "server.....images"

(which I change if I move the DB or the images folder)

Next

Main Table, container field change to a calculation field, result is container, stored, ....now I'm stuck

What's the calculation?

First

Settings table, global field, text, contains "server.....images"

... No, settings table, text field, which sets a global.

Next, Hmmm, if you've got web access, you'll have to look at a plugin if you do it this way. You might consider just setting up a second file and actually storing the images instead.

I have a further question on this topic that i have not yet tested.

If the environment is mixed (mac and PC) do you need to setup something so that the reference paths are cross platform as i assume the stored path would differ on each platform in relation to the way that the shares are accessed.

ie

PC would start Z:

Mac would start Server01/ (or something like that.

best

Stuart

Yeh,

Just use Abs(Get(SystemPlatform)) -- 1 for Mac, 2 for windows.

Sorry, my bad. I do this for my own sake and then i wrote a windows file path converter to convert to FileMaker file path.

Just set your stored field to be equal to the filemaker compatible path and then you shouldn't have any issues.

OK

I would only want to go to this trouble if the answer to Q1 was that taking the pics out and using only a reference to them would not be likely to slow down the DB. Otherwise I'll put up with the inconvenience of the bigger file.

Thanks

Phil

1 Gig = < 1 AUD ... so < .75c US

...Storage is cheap...

but i highly recommend that you do not put it in the same file. Create another file and just reference it in your main file -- otherwise your backups will be unecessarilly huge (you will be backing up pictures as well as data when you could just be backing up data).

and by data i mean majority text / numbers etc..

Yes backups was the reason for wanting the file to be smaller - I also want to take home a copy at night to work on. I'd rather email it in the morning and have the staff replace the old file, rather than getting up early myself and going in to work. Moving the pics out would achieve that end.

Is this the go?

New file, 1 Table (StaffPhotos), 2 fields: StaffID and StaffPhoto

Relate new table to mainfile:Staff via StaffID,

Insert field from related table (no need for portal as only one record per photo)

Remove existing StaffPhoto field from Staff table

Aussie dollars is good since I'm on the Gold Coast! Based on that price per Gig for storage I got ripped off big time by BigW for my 2G USB Key @ $70AUD! LOL

P.S. back to 1st question - anyone know how this might affect speed of Dbase accross small office network (Server + 7 clients)?

What about web clients?

PPS Also now that I think about it, when I had multiple files, before drawing all into one, FM seemed to keep losing the location of the other files and I'd have to select them from the Open File dialogue box, will I be back to that scenario with the photos?

Edited December 2, 200619 yr by Guest