FileMaker scripts are "layout sensitive". By that, I mean that the layout you are on and its current record determine what values you can access in that record and any records that are related to it.
In the script above, you have reference to Documents, Applicants 2, and CT all on steps 4 and 5 of the portion of the script showing in your image.
At the time those steps execute, what layout is current and what table occurrence is named in that layout's "Show records from" box in Layout Setup...?
How are these three table occurrences linked in relationships on Manage | Database | Relationships?
Thanks for the reply, unfortunately, I don't think that the layout is really the problem. SetField is not layout specific. There should be no reason that it doesn't work. The problem of course, is the question of "which record" to set, which is why I have the script SetVariable[$$GlobRecord; Value:Applicants 2::Record ID] at the very onset of the script.
The script works ONLY if there is already a previous record. I have had issues in the past with using Setfield across tables, and whether or not I need the "new record" step. If I don't have the embedded IF statement, then I create 1 record that gets written over, again and again. I want to create a log, though, so I want a new timestamped entry every single time.
The first part of my embedded IF statement works, but I don't understand why the second half doesn't. The only difference is the lack of a create new record step. I have put this in, however, and it doesn't matter. It still doesn't work.
The export field works.... so clearly the problem lies in my Else statement. I just don't understand how SetField analyzes whether or not it should create a new record... and why it breaks based on whether or not there is a previous record with the same RECORD ID number.
Sorry to disagree, but everything in a FileMaker script is layout sensitive. I'm not saying the field has to be present on your current layout, only that the layout's current record and how you've defined relationships to it will control what happens when The set field step executes. The current layout specifies a table occurrence ( a box in your relationship graph). That table occurrence has a current record, found set and sort order. When a Set Field step executes, if the target field is defined in the same table occurrence as the layout's table occurrence, the field of that layout's current record will be modified. If it refers to a field from a different table occurrence, FileMaker looks up the relationship(s) you've defined that link it to your current layout's table occurrence in order to determine which field of which record (if any) will receive the value of the expression you've entered as the script step's second parameter. Thus, the same script can behave very differently just by what layout and what record is current and at the time it executes.
By itself, the set Variable step you've underlined in your last post will not have any affect on this. It can, however, be used with proper scripting to change back to this record if your script changes what layout and/or record is current.
With regards to "new record" making a difference in how a script works, there are two possible factors: if you have a found set of zero records, there will be no current record and set field will fail. New record will correct this. Also, with a new record, your relationships for the current table occurrence may point to different related records due to auto-entered values and this may affect how your script works.
So to repeat, what layout is current when the script executes? Hopefully, it refers to one of the three table occurrence references I pointed out that are present in the highlighted portion of your script.
How are they related to the current layout's table occurrence? This detail is absolutely critical to understanding what will hapen when your script is performed.
If table occurrence is a new term, you might want to read this thread to learn more about it: Tutorial: What are Table Occurrences?
Do you have FileMaker Advanced? If so, you can enable script debugging, step through the problem area in the script, and take note of any error messages. If you don't have FMA, you don't know what you're missing! :)