About images in containers and its source

[Mreis]

H : ello everyone!

I'm building a db for by Phd investigation to be able to keep all the records available for study in one place only. Each record contain 2 fields with images (in a container field).

This images are located in a separate hard drive and I've seen that if the hard drive is shut down the FM db displays a message of "not found" in the container.

For now there is no problem with this, but, this db will be delivered for public consultation...so I'm wondering if I'm doing it all wrong and making hard work for having to do hard work again.

I don't wont to overflow this db with unnecessary bytes but if I have to get trouble twice because of the image problem I'd rather do.

Is there any "script" to later indicate the new source of the images?

Can anyone give some light here?

Thank you all

[mr_vodka]

As you have found out, if you have stored the files as a reference only and the location of those files are not present, it can not find them. You can store the actual files in the container field if you would like, but again as you said it would lead to a large file size.

Another option for you may be.

http://www.360works.com/supercontainer/

[Mreis]

Thank you,

That is an application for FM? If I use it will I not have the problems that I've described (the files uploaded will be in the db, what the origin may be or even if the origin is changed)?

[IdealData]

If you can handle the large file size then store the images in the DB.

If the DB becomes separated from the images then is the DB of any use?

[Fenton]

You can also embed the images in a separate file, and link them to the main file. You can use portals to insert the images. This allows you to have multiple images for one main record. It also allows you to take down the main file separately if you need to work on it. Its (much) smaller file size is important if you ever need to email or such.

If instead you leave them referenced as they are now, as far as I know, it is not possible to automatically retain a link to a file after it is moved.* There is however a way to use a calculated path, which can be adjusted to show the image at its new path; such as changing the server, etc.. There are several posts which describe this. But, if you expect a lot of changes, or arbitrary ones, embedding is the safer choice.

*On a single Mac, you can use "alias" files, which will always point to the referenced file, whether its moved or not. But aliases only work on your computer, hence are useless in these cases.

[eswanborg]

I do this using both methods - direct reference and calculated container fields.

So on my initial import, I capture the image as Reference as well as the file path to that image. If I am always connected to the image source everything is fine.

But I also have it scripted so that I take that core path and filename info and put it into another set of fields, which in turn are used in a calculation. That calc, returns a Container field. So what my users actually see onscreen is the calculated container (not the actual "image" field).

Finally, if I ever need to adjust the root path to those images, I can either use yet another set of fields (text and calcs) to show the alternate location, or I could just batch edit the Path info and my calculated containers would all point to the new location.

It's kind of difficult to explain in words, but it does work. I actually adopted this process because I'm also in a mixed OS environment, so having the calculated paths makes it work for either Mac or PC.

HTH at least a little bit.

[Fenton]

eswanborg, I think we need to change your profile "title" from "novice," to at least "not novice" :-]

Yes, that is what I was alluding to, and have described elsewhere. I have put the "calculated" image field on top of the "container" image field, with the calculation non-enterable. The user does not have to know the difference. So, if they Insert, it is into the regular container field. The calculation uses that to produce the image which they then see, in the same place.