photographer's new database

[skeeter]

I'm new to fm and will use it as a photo database.

Scenario #1: import alias of photo files and keep originals on the hard drive. Upside: Use less disc space. Downside: If I rearrange the originals on the hard drive I lose them in fm (as I understand it now.)

Scenario #2: Use fm as the dateabase and store the original files there. Don't keep any copy on the hard drive.

So, finally the question: Is fm a safe/stable place to keep these files. Is there any downside that I'm not thinking of?

In the near future I'll be in the range of 100-200 Gb of files. I'm thinking of setting up fm on a 200Gb external drive.

[stanley]

Skeeter:

Welcome to the Forums.

Either way, you should never only have one set of data, and you should be backing up your FM database, and your photos. In your first scenario, you'd back them up separately. In the second scenario you'd back them up as one gigantic file. The reason for this is simple: things break. Whether it's the hard drive or something gets corrupted in FMP, something may break one day, and then you'd be stuck with absolutely nothing.

One thing you might consider: if you're currently backing up your photos to CD or DVD (or tape or whatever) you could store thumbnails in your FileMaker db with a reference to the backup (for the full image) or even just a file-path, so you can find your original.

If you're storing your originals on a hard drive, you should really set up a standardized folder heirarchy, and leave your originals where they are all the time. This way you can find them easily, and FileMaker won't lose them.

So, in the end, I guess my answer is "it all depends."

-Stanley

[skeeter]

Thanks Stanley. I'll back everything up on a separate hard drive.

But I'd like to be clear on one point about the file-path. If I have thumbnails in FM and originals on the hard drive, then change my filing system on the hard drive, FM won't show a file-path anymore-correct? I would have to re-import those rearranged files into FM?? Just curious if I missed something.

It may be a moot point. As I understand you, FM is fine for storing original files and I simply back that up on a separate hard drive.

[Fenton]

These are very good questions. As you say, both methods have their pros and cons. Theoretically FileMaker can hold the data, up to 8 terabytes :-! Practically I would be nervous to put all my eggs in one basket. In any case you should take very good care of your database; backup often. Never let it freeze or crash; and when it does :-), go back to a backup, and import the newer stuff. Also keep a clean clone, in case you have to re-import all data (that would take a while with gigs of embedded photos). In other words, never use a crashed file as the ongoing file.

Here's another alternative. In 7 you can show an image by a calculation, with a container result, of the relative filepath to your images. If the pictures are in an "Pictures" folder, in the same folder as the database file, it would look like:

"image:Pictures/file name.ext"

You can use the Import Folder to import nested folders of images. But, don't import the images! Just import the file paths (and maybe the Thumbnails). Then use a calculation to remove the file path of the database from the result (using Get(FilePath)). In the case above, the result would be: "Pictures/file name.ext". So you end up with something in a calculation, adding the "image:" prefix, to produce the relative file path and show the image.

But what happens when you move images? That's the problem. One helpful technique would be to name the files uniquely. Then you can use the "Update Matching" option in the Import dialog, to match File Name with its corresponding field in the database. Import the file path again to get the new locations.

If you move a folder, you should know which, so you can Find those records in the database first. This will greatly speed up the Import. Otherwise you'd have to show all records first, which would be slow.

You cannot rename the files however, unless you use an AppleScript to do that from the FileMaker file (easy).

Another technique, Mac only. Use AppleScript to create an alias file to each file, and put them all in one folder, which would be in the same folder as the database. This is not hard to do. Each alias file is only 4K. At any time you could go to that file, and get the file path to the original file, no matter where it has been moved to. This is the power of a Mac alias. Use that to refresh the file path for any broken links.

In fact, I just tried an experiment. If you Insert Picture, as reference, or set the container with AppleScript (which is much the same thing) and choose an alias file, FileMaker will insert the original file (it will use the original's name, which might be different from the alias file's). If you move the original file, the link will break. But if you Insert the alias file again, it will insert the original from its new location, fixing the link. The point of all this is that you always know where the alias is, and the alias always knows where its original file is.

I can't guarantee this would work if you changed computers. But in my simple test of moving the whole folder to another computer, it seemed to. In any case before moving you'd be wise to set the file path of the originals into a text field for all broken links you had.

[skeeter]

Thanks. You put some work into that response. I follow the alias thinking. I need to read up on the rest. Now I wonder if I used FM for originals and it has 200Gb of files in its belly-would it be sluggish while searching?

[Fenton]

It's kind of a hobby of mine. Not really the actual photography, more the database methods involved, especially on the Mac side. So I know more about the methods than the actual performance, especially of large files.

200 GB is a lot of file size, but I don't know that it would matter so much in a search. Because container fields are not indexed. FileMaker would be searching whatever other fields you'd typed criteria in. Those are the fields that would be indexed. They are not likely to have much data size, in proportion to the containers.

There would of course be some overhead I imagine for having that much data in the file, but I think it would (it should anyway) affect searching and other operations less than you would think, far less than if you had 200 GB of text and tried to search that (but that's pretty unlikely).

Another consideration, about the photos, is whether they are large high-resolution photos. If so, you might want to create some screen sized low resolution versions for display in FileMaker, and use Insert File to store the originals. Then you'd use Export Field Contents to get the originals out again, and open with Photoshop or whatever. That way you get fairly quick screen drawing in FileMaker, and can work on the photos outside FileMaker, then Insert File again when you're done.

Has anybody done one of these projects with massive embedding?

[rivet]

just an aside, I finished a photo project awhile ago for a client and I highly recommend 'InsideScan' (www.powersolutions.it) plugin. It is very handy for creating thumbnails, getting and setting image details (meta tags), and most important you have the ability to manipulate the file paths incase you have to move the originals as well as creating sophisticated import and export scripts.

small learning cure, tones of power

good luck