I'm not sure that I have this correct, but it seems that you have this relationship:
Vehicle Incident Report::xzE_VehicleID = Corrective Actions 3::xC_vehicleID AND
Vehicle Incident Report::g_CorrNum = Corrective Actions 3::AppCorrNum
And if g_CorrNum is a serial number field that can't be modified, why do you then use a set field script step to modify it?
Note that in many databases, g_ is used to identify fields with global storage. If it's a serial number field, this would not seem to be the case here.
For your report, my best guess is that you should add a new Occurrence of Corrective Actions linked like this:
Vehicle Incident Report::xzE_VehicleID = Corrective Actions 4::xC_vehicleID
And then a portal to Corrective Actions 4 should list all related records.
But your original set of relationships looks odd....
Sorry it seems strange! its from advice I received from my FileMaker teacher. Here's exactly what he said:
You’ll use a global field in the following way (this threw me at first, but see if it makes sense, it works like a charm).
-- In your Applicant table you’d have a number field like g_ExpNum set to global storage. In your Experience table you’d have a number field like AppExpNum that was not globally stored.
-- On your relationship graph you’d link your Experience table and your Applicant table by BOTH the Applicant ID (say, xP_AppID which would be the auto-serial in Applicant and xF_AppID which is just a number field in Experience) AND the global field g_ExpNum. Make sure to check the box to allow records to be created in the Experience table from this relationship, as that’s what you’ll be doing when you say “add more experience”
-- On your layout (which is based on the Applicant table), in the Experience tab, you’d place fields from the related table occurrence you just created in the Relationship Graph.
-- The “Add” button would have a script that increased Applicant::g_ExpNum by one. The fields would all immediately go blank for the new record and the relationship would automatically populate both the xF_AppID and AppExpNum (assuming you used the same names I showed here, which you don’t have to).
This was for a totally different database, but I've just used the same strategy. This was also what he said as added notations later;
Just to be sure, the xP_AppID should not be truly “global” if it is a serial number. Global means there is only one value for all records in the table, and the idea with a serial number is that it’s different for each record. I suspect you have it correct in the database and used the word global to mean something else. I certainly double up my words too often and my students were patient with me :)
Yet the relationship that you specify only matches to a single record. That can be useful in certain cases, but not when you want to use a portal to display multiple related records. That's why I suggested adding another table occurrence so that you can set up a relationship that only matches by the first pair of match fields. Then a portal to this new table occurrence will list all related records.
PS, part of what was confusing is that this statement from your original post is contradictory given that g_ denotes a field with global storage: (contradictory text in red)
there is field g_CorrNum (serial number field, can't modify) related to field AppCorrNum (standard number field)