Any chance you have more than one portal on this layout?
Go to Portal Row should select a portal row on your "current" portal if there are more than one such portals on your layout. By clicking in the field, you've made that portal the "current" one and that's what has me thinking of this possible cause.
Before the go to portal row step, use either Go to Field (specify a field unique to the portal you want to select) or Go to Object (use Object info palette to give the portal a name.) to select the desired portal.
A better approach might be to use other code that achieves the same result without directly interacting with a portal. You could, for example, freeze the window, switch to a layout that refers to your portal records, create the new records, set the field values (including the foreign key field) and return back to your original layout.
There is only one portal in the layout, so FM should not get confused about which portal is meant. But I got it working by having that "Go to Field(one of the portal fields)" as the first step in the script. It gives me an annoying flash, though, when the cursor first activates the field in the first portal row and then in the next script step moves to the last "new record" row. Oh well, I think I have to live with that. It is not such a big deal.
But I think it is definitely a bug in FM10. In FM4 it works as expected.
If you are dealing with a bug, it is Mac only. But, as I questioned you on FM Forums: 1) From layout mode, have you made sure that the fields within the portal all match the portal table occurrence and 2) You say you 'imported' from FM4 to FM10. Did you let FM convert it for you or did you import the fields and data and re-create the proper relationships?
You do NOT need Go To Field as opening step - your script works perfectly on FMPA 10.0v3 and FMPA 9.0v3 on Windows. I suggest you attach your file to the other forum (where they allow files) so we can identify the issue or use a file sharing service to upload it. :^)
your script works perfectly on FMPA 10.0v3 and FMPA 9.0v3 on Windows.
It works perfectly well in FMPA 10.0v3 under OS X, too.
That is assuming Go to Portal Record(Last) means Go to Portal Row [Last].
Because I often enter portal records with several fields having the same data, I have a few variable fields on the layout and a pushbutton launching a script that does:
Go to Portal Record(Last) - this creates a new portal record
Set (portal) field x from variable x
Set (portal) field y from variable y
Go to Field(Z) - this is where I want to enter values.
This woke me up. What do you mean by variable? If you are talking about using a script variable then that's the issue ... you must set the variable with a value at the beginning of your script because script variable values only persist within the script. If you are talking about using global fields, are you sure portal field x and field y inherit the global values? Have you placed fields x and y in your portal to be sure?
If that first Set Field step is trying to set field x and the variable doesn't contain a value, then you won't get a new record created. Neither will your second Set Field for possible same reason. What is left is Go To Field  and it will go to the first portal record at that point. Why it would work if reversed (going to field first) is that, once you are in the field then go to portal row last, you typing your final value is what will create the record.
UPDATE: Comment said, "That is assuming Go to Portal Record(Last) means Go to Portal Row [Last]."
I assumed that's what was meant and I probably shouldn't have assumed. I also wonder if there are script triggers attached somewhere but I strongly suspect issues with the first two Set Fields
The variables I am talking about are global fields in the main table, not $-variables, and they are ok - they contain the values I want to add to a new portal record.
And yes, I meant Go to Portal Row(Last). Was writing it out of memory, so I picked up the wrong word.
I have done some more testing, but still haven't found the reason. Maybe the file got slightly corrupted somehow when importing... but everything else works as expected. So I just don't know at the moment.
If you have Filemaker Advanced, it might be enlightening to run your script with the debuggers so you can watch what happens step by step.
That was the first thing I did. But it showed nothing helpful. Only that the cursor went to a wrong row (second last), updated the values there and then went to the first row to wait for my input.
I have seen corrupted layouts where odd things like this happened. On the other hand, we don't know exactly what's in your script and layout either.
You can try making a new layout and testing it to see if the script works correctly on a new layout.
You could upload your file to a share site where others can take a look at the actual file to see if they can spot the problem.
You could also make a database design report, copy the script from it and post it here also.
... all things I've already recommended including upload for our review, checking table occurrence and fields and so forth. Since we haven't been answered on several of the questions, I won't try guessing any more; it wastes everyone's time. It is far too easy to suggest it might be corruption when 99% of the time, it is something simple. I don't even see where it was verified that 'Allow Creation' has been turned on.
The ball is back in their court... :smileyhappy: