My crystal ball is once again down for repair.
On what table occurrence is this layout based?
What does your actual relationship graph look like?
If you manually edit that field to get a matching value, do your relationships work as expected?
Are all of the fields shown edit boxes? (no value list formatting used here?)
This layout is based off the Production Cost Sheet Table.
The actual relationship graph looks identical to what I've created in this layout.
Sales People::Sales_ID = JoinTerritories::Sales_ID
JoinTerritories::Territory_ID = Territories::Territory_ID
Territories::Territory_ID = Production Cost Sheet Territory_ID
Some of the relationships have the "Allow create and deletion" options checked.
I cannot change the Sales People::Sales_ID to the correct value, because it's the PK for the Sales People table. It's unique and auto generated on record creation.
Yes, all the fields are edit boxes.
Without a screen shot of the relationships graph, it seems that the relationships you describe look something like this:
Sales People----<JoinTerritories>-------Territories-------<Production Cost Sheet
note that ----< means "one to many" in my notation.
I cannot change he Sales People::Sales_ID to the correct value....
But I was asking you to edit the JoinTerritories::Sales_ID field, the foreign key, not the primary key.
But what you show in your screen shot appears inconsistent with what you describe as your relationships. Either your relationships are not what you report, or there is something wrong with the design of your layout--such as selecting an ID field from the wrong table occurrence when setting up the layout.
If you add a portal to JoinTerritories to your layout and add the following fields to the portal row, do you still see SalesID values that do not match?
You are correct in the relationship. Here's a picture of the graph, sorry for it being messy but I had to pull them all close enough to get a screenshot.
When I put a portal to the Join table with the requested fields, here's the result.
Here is the Portal with the same fields to the Sales People table.
What I see confirms that your relationships and data are correct. Any apparent "mismatches" of the sales ID are layout design based issues.
Take your second portal--which appears to be based on Sales People instead of the Join table.
You get the same JoinTerritories::Sales_ID field in every portal row because you have referenced a table occurrence that is on the "wrong side" of your relationships to work the way you expect it to work when put on a layout based on
Production Cost Sheet. FileMaker evaluates this from a "starting point" based on the current record of Production Cost Sheet, not a specific record in Sales People. From the current Record in Production Cost Sheet, any reference to JoinTerritories::Sales_ID will refer to the first related table in the join table and thus all show the same ID value. In order for the Sales People to show data from JoinTerritories but from the context of each portal row's record, you'd have to add yet another occurrence of JoinTerritories and put it on the "other" side of this chain of relationships:
Production Cost sheet>-----Territories-------<JoinTerritories>------Sales People------<JoinTerritories 2
Given those TO's, you'd add fields from JoinTerritories 2 instead of JoinTerritories to your Sales People Portal.