Your are limited to one file to each container field. but you can define more than one container field. And even better design, you can set up a related table of records with one container field to each record and then you can add as many related records with photos as you need and have them all linked to the same parent record.
Thank you PhilModJunk. I appreciate your time and help.
My database is one for my pottery. I do a lot of research and want to have a dynamic way to use this research in furthering my understanding of my work.
The basic situation is that a Pot can have many Glazes, and a Glaze can be on many Pots. A Pot can also be in many Firings, and a Firing can contain many Pots. I have set up Join Tables which link Pots and Glazes, and also Pots and Firings.
On the Layout below, the Firings portal and the Glazes portal are supposed to dynamically display the "many" Firings a Pot might be in, and the "many" Glazes that the Pot might be glazed with. It does not seem to work, and I'm sure I have an error somewhere.As you can see the container field has only one image in it as I thought there might be a way to get multiple images to work. Does your suggestion refer to setting up a portal between the Pots table occurrence, and another table that contains images? Since I am a beginner in FileMaker, I don't really understand your answer.Thank you again. And thank you, everyone.
Since these portals do not seem to work, I'm posting a screenshot of the Relationships graph.
Each Pot has a unique number, and I'm now over 3000. Each Glaze and Firing also have unique serial numbers, and these are the primary keys for the 3 tables.
Is it obvious to anyone why these portals do not work from the Relationship Graph. I did click on the little equals sign buttons between the tables and told them that it was OK to "Allow creation of records in this table via this relationship."
Thank you again, everyone.
portals to which Tutorial: What are Table Occurrences? and placed on a layout based on what table occurrence?
From a layout for Pots, you can place a portal to any of the other 4 table occurrences shown here. Portals to the join table are useful when you need to link a pot to a particular glaze or firing record. But a portal to Glazes and a Portal to Firings can list all the Glazes and Firing records linked to the current Pot record showing on your layout.
Thank you again PhilModJunk.
I've had a hard time with the portals working but I think I have the correct idea now. I was trying to link Pots and Glazes directly through their Primary Keys, and I was able to enter one glaze for a pot, but then could not enter any more. And the same with Pots and Firings.
The basic idea is that I need to design a Layout that will allow me to enter all the information about a particular pot -- the glazes that are on it, and the firings that it is in. If I'm correct, that Layout will come from linking the Pots table to the PotsGlazes and PotsFirings Join Tables. I'm about to try to do that now.
I'm learning this on my own, with access to Lynda.com and Cris Ippolite, which is an incredible resource, but which does not allow me to ask questions.
So I thank you again for taking the time to help.
Yes, that is what I have recommended that you do.
You may find this older format demo file a useful source of ideas for working with many to many relationships like you have here. It links "contacts" to "Events" in a many to many relationship. There are different layouts and scripts that deal with a number of issues that you may encounter when working with such a relationship.
Since you are likely using FileMaker 12 or newer, use Open from FileMaker's File menu to open this file and produce a copy converted to the newer file format.
Thank you very much.
I'm not having much luck with making mine work so I'm headed to your fraternity party.
Thank you for your example.
If I understand you correctly, in my situation, what I need to do is base the Layout for entries into Pots and Glazes on the PotsGlazes Join Table. I want to be able to enter a pot number and the glazes that are on it, but I also want to be able to enter the firings it's in too. Would this not be based on a different table?
I thought a Layout had to be based on just one table.
Sorry for being so confused.
You would base your layout on Pots and add two portals, one to potsGlazes and one to PotsFirings.
You'd link that pot to a Glazes record in the PotsGlazes portal and Link that same pot to a Firings record in the PotsFirings table.
Make sure to enable "allow Creation of records via this relationship" for the two join tables for each of these relationships.
To compare this to the demo file, All but one of the layouts are based on different table occurrences of Events with portals to related table occurrences of Contact_Event. "Events" is the equivalent of your Pots table and Contact_Event is the equivalent of one of your two Join tables. (A Tutorial: What are Table Occurrences? is one of the "boxes" found in Manage | Database | Relationships and is used to define relationships between tables. It's possible to have more than one table occurrence for the same data source table in order to define different relationships between the two tables.)
I used your example and it works!
What I understood before trying to make these portals was that the Join Table has a (potentially enormous) collection of pairs, and that each Primary Key looks for itself in the Join Table and finds the unique pairs that it is associated with -- but somehow I kept making mistakes, over and over.
But your explanation helped me and now I think I understand.
When we say, "Allow creation of records in this table via this relationship," what that actually means is that as we enter information in the Pots Table, we are defining these pairs in the Join Table on the fly, which is what we want to be able to do. And then this information is available to the other side of the relationship, via a portal, in exactly the same way, as long as we "Allow creation . . .
Thank you again. If there is a mistake in my thinking please let me know. I want to understand everything -- from the bottom up.
More on "allow creation of records via this relationship" and portals:
When you have a portal and enable this option for the portal's table in the relationship, you'll see what looks like a blank record in the portal after the last actual record in the portal. I call this the portal's "add" row because entering data into a field in this row adds a new record to the portal's table and automatically links it to the layout's current record. It does this by copying the value of the current layout record's match field into the corresponding match field of the new portal record.
In the case of a join table, if you select or enter a value into the _fk field of the match field that matches to your glazes or firing table, this does it all in one go, entering the data updates the _fkPotID field to link it to the current pot record and the value selected or entered links it to a record in the third table--either a firing or glazes record. But keep in mind that if you have other fields in this row and enter data into them instead of the _fk field for the third table, the new record is then linked to the current pot record, but it is not yet linked to a record in the other table.
The main draw back to using this method to add new portal records is that you have to scroll to the end of your existing records each time you want to add a new portal row. For large numbers of portal records, this can be less than ideal. Thus, many developers prefer to set up a sort order on the portal and a scripted button such that clicking the button adds a new blank record at the top of the portal. (The sort order puts the empty record at the top after the script creates the record.) This saves having to scroll the portal each time.
Thank you from saving me from myself. For some reason, I made the Primary Keys in the Glazes and Firings Tables serial numbers, even though the names of the glazes and firings are unique. I now see how this would not have worked in its present state. I will go back and change them.
It would be rare for me that any of my portals would contain more than about 5 lines. Perhaps a firing would have more than 5 pots in it, but that's all. It's good to know that I can set up a sort order on the portal, even though I don't yet know how to do it.
I'm still playing with the Layout design but here is where it is now.
The ID's should be auto-entered serial numbers. They should not be names. Using names opens the door to issues with your primary keys that are avoided if you stick with auto-entered serial numbers.
My IDs are auto entered serial numbers, except for the pot numbers, which have been getting larger since the early 80s. I've made just over 3000 porcelain pots since then. I've specified that they have to be unique, and that I'll be warned before entering a duplicate number.
I think what you were saying is that only the keys are moving through the Join Table. So if I enter the first glaze 063013 LB21, which has a serial number of 1, then when I'm at the Glaze Table, I'm going to see a 1, and not 063013 LB21. So I have to enter the glaze name twice. Is this correct?