Your relationship looks like it is set up correctly. You may have a problem, instead, with the design of your layout.
Please describe the design of your layout and the portal. What names you've selected in "show records from" and "Show related records from" could be key here.
Also please explain what you mean by this phrase: "But when I look through a portal on the PN side, I see all the photos, but it does not find the related HN correctly" Exactly what you mean by "look through" and "find" in this context could be significant.
Phil, Many thanks for your reply. Im going to send a series of screen shots showing the contents of the tables, and the designs of the portals. The glitch occurs in the PN layout. photos-10003 should be related to HN-1001. But as you can see in the portal, it is showing HN-1000.
As you can see from these HN records, the portal is finding the correct photos.
These two screenshots show the records for the portfolios that are correctly linked to PN-100 and the respective HN-1000 and HN-1001
And these are two records (out of 4) showing that the photos have been added to the portfolios with the join table.
And finally, look how I have changed the portal design to Show from photos. This still returns the incorrect HN-1000 for photo-10003
I see the problem. Your fields in the portal from Photo_Portfolio, PN and HN will not return the values you expect here in every case. Here's why:
You have a many to one relationship from Photo_Portfolio_Add_Photo to the join table. The fields reference back to the first related entry in the join table and this isn't always going to be the record you want here.
::HN_ID_PK will return the ID of the record linked to the FIRST record in Photo_Portfolio with the same Photo_Portfolio_ID number as the current portal record's.
I confess to being puzzled by the presence of the Photo_Portfoloio_Add_Photo table occurrence and it's intended function. Is this a separate table or an occurrence of one of the others shown here? Why do you need it here?
Hello Phil, I did it that way because there may be instances where the same photo will be used in a different portfolio.
Would you reccommend another way of doing this, so that the proper HN-s will be tracked for each portfolio?
I did this much more complex structure that works, but Im wondering if there would be a simpler way to accomplish.
In your last image, you have the Master Key table occurrence collapsed so I can't see how the relationships are implemented.
I think your original relationships might work if you based your layout on a different occurrence such as Photo_Portfolio instead of HN or PN. Of course, that can also depend in the desired functionality for this layout as well...
Sorry about that. No matter what I seem to try with that portal layout in the original, I can't seem to make it work.
Here are the screenshots for the more complex diagram, and a view of a PN reocrd showing that it finds ALL the photos AND the correct HNs as well in the portal.
Hmm, that's definitely a different approach. I'm still mulling over the implications of it. On what table occurrence is the layout shown based?
I keep coming back to those two linked join tables. What is the role of a portfolio here? It would appear to be defined as a set of photos taken by a specified photographer of/at a specified location. Is that correct?
Hi Phil, I think the reason my simpler approach does not work is a flaw in the foundational logic of Filemaker.
Let me explain the more complex one.
The 5 tables on the left are considered "high domain" tables. While each has a unique ID for the TYPE of table (HN_ID_pk) they are all given a unique "apex" ID found in the Master Key Table. (MK_ID_pk) What this allows is for me to:
1. First establish a "relationship" between two tables on the left. This is achieved with the Relationship_binder and the Relationship tables. So you can see that in every "high domain" layout, one can see what Relationships occur.
2. One a relationship is established, then an attribute key field is populated in the Relationship table. So, if a "Relationship" is one of Place (PN) to photographer (HN) then the actuall "assignment for that photographer, from the assign_photography table is inserted in the appropriate field.
3. Then photographs made by the photgrapher are linked by populating the _assign_photography_ID_fk field in the photographs table.
4. Finally, for this to work, I add a table occurence HN-1000 so Filemaker can properly find the phontographer.
Ive wrestled with this for a long time. What this essentially does is allow "Reciprocal" relationships between the "high domain" tables on the left.
I am very hopeful that this is really a good solution at the base level. So if you'd be willing to discuss on the phone, at your convenience, Id be grateful to get your insights.
These two screenshots show how on the HN side, you can see all of the photos taked by this HN, or in another branch, all of the "stories" writted by this person.
Also see, it correctly lists all of the relationships engaged by this HN.