Try using Commit Records instead of Refresh Window. You can test this situation without changing your database by clicking a blank area of the layout background to commit records. If you click either + or -, then click a blank area of the layout and then the portal's update, you just need to include Commit Records to your script.
You may need commit records followed by Refresh Window.
Wow. Thanks for the quick response.
Excellent thought, unfortunately, the do not include portal still does not update. This did however fix another script I had. Previously, to get the list to update, I went to the next record and then previous to commit. Had a couple refreshes thrown in there but the commit step allowed me to remove 4-5 lines of the script. That's always good.
So... the list field is correct but the relationship does not seem to update. I did find out that if I go into the "Manage Database" and then back out, the portal will update.
EDIT: I've also noticed that it will refresh by waiting about 2 minutes and then running a script that goes to a different layout and comes back and refreshes the window.
Is the portal filtered?
Does refresh window [flush cached join results]
make it work?
I don't recommend this option as a permanent "fix", but if that works, it provides us with a useful clue here.
I've experimented with and without filtering.
I completely forgot about the flushing cached join results option. This worked without issue. This particular layout and scripting is used very rarely, perhaps a dozen times a year. Is there a more permanent solution? Due to the rarity of use, I am perfectly fine with the flushing solution.
It's a matter of how long it takes for the window to refresh. This option can, under certain circumstances, result in long delays waiting for the screen to update--particularly if you have one or a combination of the following:
A Remotely located host computer (such as from a hosting service)
A very large set of related records in the portal--especially if there is conditional formatting set up on fields in the portal row.
iOS based clients using FM GO
But what you report is consistent with having a portal filter set on your portal where data changes require that the filter expression re-evaluate in order to update what records are allowed to show in the portal. But when that is the case, there are alternate approaches that can be used in place of Refresh Window[ flush...
Yeah. The EDS is half way across the country. There's only going to be a max of 10 or so related records, per each record, in this reference. Also, we do not currently have FM GO involved, and it is doubtful that this portion would ever be accessed from an iOS device.
I think your solution will work great. Thanks again. Have a good on.