1 of 1 people found this helpful
Short answer is no, there's not a limit of container fields per record. However, you may run into issues embedding images directly into your database, because, as you suspected, this will bloat your database file and impact performance (especially over the network).
There are no real advantages of creating a separate database file containing just the images and building a relationship to that (assuming I've interpreted your question correctly). You have the same issues when you embed the images. However, that doesn't mean you don't have other options.
You can store container data in essentially three ways:
1) Embedded in the containers.
2) Stored by reference (meaning the asset remains in the original location and the container field stores only a path to it).
3) External storage (available starting in FileMaker 12), where the asset is stored in a specified directory relative to the database location and managed through the FileMaker interface.
Some additional details might be in order. For example:
1) What version of FileMaker are you running?
2) Are you running this database locally on your hard drive, or is it hosted using FileMaker Server?
3) Are there other users of this database?
4) Do you give other people a copy of the database to use, or does everyone use the same copy via Server or other sharing?
You say you have potentially "hundreds" of images. In such a case, I would normally recommend storing the assets externally to the database file, either by reference or using external containers (if version 12 is available). However, if the database is meant to be passed around to different users, then storing the container contents by reference is likely to cause issues unless every user has access to the original directories AND can resolve the embedded paths correctly.
Maybe if you give us a little more information, we can point you in a more specific direction.
Thank you so much for your detailed answer!
I just wanted to answer your questions:
1) What version of FileMaker are you running? -> FileMaker 12.ov4
2) Are you running this database locally on your hard drive, or is it hosted using FileMaker Server? ->locally on my hard drive, although I'm going to look into FileMaker Server now
3) Are there other users of this database?
4) Do you give other people a copy of the database to use, or does everyone use the same copy via Server or other sharing? -> Right now it is just myself and my boss working on an archive of her textile collection, but hopefully in the future we want to be able to share the database with people who express interest in seeing the collection. I need to find the best method of storing images so we can fulfill this goal.
Embedding images in containers might make the file too big. Some files have upwards of thousands of images. Although I'm still going to just try it, bc it seems like the simplest solution.
Storing by reference might cause a problem if we want to share the database with other people, bc they won't have the same file paths on their computer.. Should I just keep a folder of images with all my Filemaker data and remember to include it with the database when I share? Or should I make a separate but related image database bc it seems more professional than sending along a folder of images? Also, how do I learn how to make a separate but related image database.. would you be able to suggest a link? Is it called a "related database"?
The last option you mentioned- external storage sounds interesting. Do you have to upgrade the software to get this option or can I implement it now to test it out? Is there a link with more info about this? Is this the same thing as FileMaker Server you mentioned above?
Thank you for your help and patience!
If you want to embed the images, I would do as you suggest. Have all the images in a folder in the same directory as the database and include that folder when you share it with another person. Not ideal, but better, in my experience, than embedding them.
External storage for containers is a new feature of FileMaker 12. An upgrade is not required. You set the option in the Manage Database dialog by selecting the container and clicking "Options", then the "Storage" tab:
That bottom section is what you want. Check "Store container data externally" to activate it. FileMaker will automatically create the directories it needs for you.
CAUTION: Once you select external storage, you MUST only interact with the assets (the image files) through the FileMaker interface. If you attempt to add / delete files directly in the referenced folders (i.e., through the OS), it will break the linkages to the container fields and FileMaker will report it as a bad link. (I forget the exact error message.)
With regard to a separate database - there's really no need. But to answer your question, you create a second database file. Then link to it on your Relationships Graph by adding a table occurrence that points to that file.
More information can be obtained through the Help.
Thank you so much for your help!!!
1 of 1 people found this helpful
Is there a limit to the number of container fields I can have in a record?
yes. 256 million total fields over life time of file.
(Some of my records have up to 4 images, and I've been running into some glitches at container field 3, and my image files are not that big- around 3 to 4MB).
Whenever you want to store lots of the same thing and you don't really know how many you will need you should think about using a related table. Look at the example files that came with filemaker for starters. There is probably one that does what you want.
Is there any way to source images directly from a photo in iPhoto?
yes. When you choose "insert picture" the file browser opens. In the column on the left scroll down until you find "pictures" folder. Click on it and it displays iPhoto collections.
Will embedding hundreds of images in my file cause problems with file size and speed (I am using OS X 10)?
That depends on what you do with them.
What are the advantages of creating a separate image file that is related to my main file?
It's all about managing resources. At the outset it is easier to do it the obvious way (create a new container field each time). After a while you'll begin to wonder why you need to create a new field each time you want to add a photo to the database. Then you'll start to think about restructuring your database.
wow thank you so much!
You've already received much good advice from some really good developers, but I wanted to point out a couple of things.
First, in v12, organizing your images in the same file as everything else makes (in my mind) a whole lot of sense. But, even if they are in the same file, if you want flexibility regarding how many images might pertain to each other entity/thing/table (e.g., person, location), then you will probably want your images in a separate TABLE.
That said, particularly in pre-v12 solutions, there have been some good reasons to keep images and other binary data in a separate FILE (even if you decide not to use the typical "Data Separation Model"):
1. Options for separate backups
2. If a binary file gets corrupted, it can corrupt the whole file, so won't impact the primary data file
Just my 2 cents.
It sounds like having a separate related table for images has definite advantages. thank you so much for your help!
What Malcom and Debi are alluding to is the merits of good relational design. They're both quite correct. I suggest you pick up a copy of the FileMaker Training Series and go through it, paying particular attention to Module 3, which discusses data modeling in some detail.
(As an aside, Debi's warning about file corruption due to a bad binary is a very good reason NOT to embed your assets into your data structure.)
thank you again Mike for all your helpful comments!!!