Portal not updating with scripted window refresh

[mswscco]

After creating a related record in a second window, I have a script that closes the window, returning me to the original window where my portal is then the final step in the script is to perform a window refresh.  Unfortunately, the portal does not show the updated record until I manually perform a refresh either with the keyboard shortcut or from the menu bar.

 

I think it has to do with the relationship being based on a global field (I've tried both global text and calc fields with the same result).  Is there an easy workaround that I'm missing?  Thanks.

[comment]

After creating a related record in a second window, I have a script that closes the window, returning me to the original window where my portal is

 

Are you committing the newly created record before closing the window?

 

Please provide a better description - one that would enable us to reproduce your problem.

[David Jondreau]

And does your Refresh have "Flush cached join results" checked?

[comment]

And does your Refresh have "Flush cached join results" checked?

 

Does it need to have "Flush cached join results" checked?

[David Jondreau]

Probably. Joins based on globals benefit from a Refresh[] with flush. A Refresh[] alone won't do it. That's also true when you're just changing the parent global field. You'd need a Commit[], then a Refresh[] flush then.

 

But the only person who can say if it needs to be checked is the OP, by testing it.

 

Also, if the original window has the cursor in the portal itself, even if the relationship is not based on a global, you've got to either Commit[]  to close that open record or Refresh[] with flush. So, if you're going to toss a Commit[] in there, do it after the Close Window[].

 

A Commit[] before a Close Window[] is simply redundant. Closing a window is a committing action.

[comment]

A Commit[] before a Close Window[] is simply redundant. Closing a window is a committing action.

 

Fair enough. I don't know about the rest though, esp. this part:

 

Joins based on globals benefit from a Refresh[] with flush.

 

The thing is, I am unable to reproduce the OP's problem - so it doesn't look like global field is the issue here. And AFAIK 2x Refresh Window is not the same as a Refresh Window [Flush cache], so it seems there's something else at work here.

[David Jondreau]

OK, I did some more testing and everything I said above was accurate for global fields being used to filter a portal, not for global relationship key. However, if you have modified a global field and not yet moved the cursor from the field, then running a script which makes a new window, goes to a layout, etc, etc does not change the relationship.

 

I'm avoiding using the word commit here, because modifying a global field does not open a record and hence doesn't create a "committable" situation.

 

 

Perhaps the OP has a filter on the portal? Or some other conditions that may affect this (does a related file make a difference? ESS?).

 

Another relevant point is that the menu generated Refresh appears to be a Refresh with flush, so it's not a "double refresh".

[mswscco]

Wow, thanks for all the replies.  Here are some more details:

 

Table Home has field gHidden related to field Show in table Messages.  As long as Show ≠ "Hidden" the record is supposed to show in the portal on the Home layout.  The home layout has a button that runs a script to create a new record in Messages in a new window.  The Messages layout has a button to commit record, close window, refresh window.

 

I think my original suspicion regarding global fields is wrong.  The portal does refresh properly whenever I'm editing existing records in table Messages.  It only requires the manual refresh after a creation of a new record.

 

Hopefully this sheds some more light.  Thanks.