Are the fields that are in the portal the right context? That is, are the using the same TO as the portal?
You might benefit from reading a white paper on the Relationship Graph. FMI has a Developer's Conventions whitepaper that helps you approach the relationship graph in more complex solutions. I am a fan of the Anchor-Buoy methodology. Your Project table isn't overlinked, it is that FM won't allow circular references in the RG.
Where can I find the FMI Developer's Conventions whitepaper?
I've cut up the RG so my join is connected to a copy of my Projects3 and Items tables seperately.
My Items layout can see Projects through a portal. My Projects layout can't see the related JOIN table or Items table.
However, if I make a new layout (based on Projects3) I can see items through it. This brings about a huge problem because I don't want to re-layout/design a Projects3 layout when I already have one that works. Is there a way to relink the original Projects layout to Project3 in the RG?
At some point you will need to redo your relationship graph. I'd go for it now. It'll pay off tremendously as you build more complexity.
It works from the context of Projects3 bcs there is a relationship to the Join. If the layout is based on the Projects TO, then create a relationship to the Join from Projects.
You must understand the concept to context in FM. Think of it as the room you're in and any relationship is a window to another table. If you're in a room (TO) without a relationship to another TO, then you can't see another table.
Thank you for all your help. I think my solution was strongly about grasping the circular-reference issue that FM won't let happen.
I rearranged my RG to look like the a/b method. I feel good about more ambitious solutions with Filemaker.
I think I may have the same problem.
This is a film company..that has a CLIENTS (table) which created new PROJECTs (table)...and we have CREW (table) working on multiple projects and sometimes appear in multiple portals in a project - we have other things going on like TALENT and VENDORS..but it should not be relevant here since all those portals work.
The Portal success is that CLIENTS layout portal can see all their projects. - nice..and how much they owe etc.
RE: CREW portal
Need to see a PROJECT PORTAL on CREW LAYOUT which shows the PROJ ID and NAME AND.. INCIDENTS that a CREW member has been in on the surrounding tables..
Each PROJECT Unique ID.
2 UNITS or film crews per day.
Each UNIT is a portal has their own incident table (D1 U1, D1 U2 or ( Day / Unit ) ) because the same Crew member may be on two units that day or on multiple days. (this portal selection of crew members works nice and we get their photo, cell phone etc on the call sheet -nice!
Each incident/record pull their DAY rate /HALF DAY rate and calculates their rate in that incident. We can manually adjust the rate and number of in that incident/record.
Ok..so now all those incidents where CREW appear on a project (various days and units) from those various incident tables...do not show up on their individual record in the CREW layout. I did complex relation connections and simple ones by just linking the PROJ ID..which is the primary KEY FIELD used on the main relationships you see coming off the PROJ Table.
I've seen that too many relationships can mess things up..all links to the Call Sheet work nice with merged fields..but..when I try to seek out all incidents for the units (each record in each incident table has unique ID key field)
But I've tried everything I've read and even been on Youtube videos for answers..its probably simpler than I'm trying to make it.
Do I need to create a new incident table (with a new Record ID) to bring together all the incidents created for that crew member?
See what I have below.
Somehow that upper main CREW table must generate a portal that can see all the other records that are created in those other highlighted tables. I have limited scripting abilities and don't understand the more intermediate scripting using variables.
But my Database looks great and super-user friendly..! which is probably my design skills coming through.
Just feel like I've hit the wall! If I can get this multiportal concept to work..I will feel like Wonder Woman. If I can get a solution..I'm going to play the theme in the office.
Looks like your database is suffering from an excess of tables. Just using your Crew D1 U1 through Crew D6 U2 tables for an example, you can store all those records in one table by adding a pair of fields to identify the day and the unit. You can then use these new fields in relationship and when performing finds to find all related records for any given day and unit designation.
With just one such table, your entire database then becomes much, much easier to work with.
yes..I thought of that..but would I be able to create separate portals when selecting during input?
As I have below..we think out the day's events..and who needs to be there in that unit..and make adjustments to their rate and order of call time...visually. We have to constantly adjust information..remove and add people.
You can set up a filtered portal or portals to display just the information for once such group of records.
If you click the advanced search link and search under those terms, you'll find lots of examples of this method.
Thanks so much..I'm going to lookin to "Filtered Portals"..and see what I can muster.
Get back with my solution.