Changes to the value of the global variable will not automatically update what you see in the portal. Follow the change to the variable's value with this script step:
Refresh Window [flush cached join results]
and see if you get what you want in the portal.
If that works, I can describe an alternative method using a global field instead of a variable that will not need this rather drastic method of getting the portal to update.
Nailed it Phil. I can also see how then a global field would work instead. I /have/ been using those in other situations but thought this would work as well. This is fine in a pinch as this is just to print a rental agreement and is not done heavily throughout the use of the DB.
With a global field, you can modify the portal's relationship so that you can still use the filter, but not need any refresh window [flush...] step to update it.
But since your portal filter is not specifying anything that really needs to be put in a filter, I'd just add the global field as an added match field in most cases.
(But if your portal filter expression were to use a more sophisticated expression than just matching exact values via the = operator, you can make the following change and then your portal filter will update automatically when the global field's value is changed:
Say your portal filter expression now is:
LayoutTable::PrimaryKey = PortalTable::ForeignKey
Change it to:
LayoutTable::PrimaryKey = PortalTable::ForeignKey AND
LayoutTable::globalField X PortalTable::anyfieldyouwanthere
Adding that global field in with the X operator won't change what records show as related, but it forces the portal filter to update each time the value of the global field is updated.