This only works if "Allow creation of records..." is not enabled for your portal's relationship. Each time your script uses set field to assign data in the last row of the portal, a new record is created and a new portal row is added.
You may want to use something like this:
Set Variable [$Rowcount ; Value: Count ( PortalTable::ForeignKey ) ]
Go to Portal Row [Select;First]
Set field ...
Exit Loop If [$Rowcount = Get (ActivePortalRowNumber )]
Go to Portal Row [Select;Next;]
It's usually better to not try to interact like this in the portal to begin with. Instead, your script can freeze the window, pull up the records on a layout based on the portal's table, do whatever processing is needed with this found set of records, and then return to the original layout.
That avoids layout changes that could otherwise unexpectedly "break" a script that interacts with the portal rows.
I see and thanks.
The reason I use the portal row loop is because I have Save/Revert buttons which allow use to drop their change. Loop to set portal row field can be reverted while using the other layout found set cannot be reverted.
I'm afraid I don't follow you there. How can you revert changes made from a script that loops through your portal rows? Once you go to the next portal row, the change to the previous portal record is committed isn't it?
I followed your suggestion to place a Web Viewer to covert entire screen area. With it, the auto commit will not be trigged. It allows user to decide save or revert before exit the layout or got to next record.
Yes, but I didn't think that would work for the portal rows as these are separate records from the layout's table where you've prohibited the auto save. I'd think that if you reverted your layout's table, the fields in the rest of the layout would revert, but not changes to data in the portal rows...
Honestly haven't tried that exactly though I have something very similar in my Known Bugs List database so I guess I'll need to experiment to make sure that what I just posted is accurate.
Interesting. A quick test reveals that you can revert the portal row changes. Learned something new! and this raises interesting questions as to how FileMaker edit locks portal records in this situation as well...
Yes, it works. I did test it before I implemented it. It works perfect for the save/revert feature which is kind of important for some application. I can revert entire layout, including portal rows.
It hadn't worked before for me because I needed to add a triggered script to a portal field that had to commit the data before changing layouts to do some behind the scenes stuff. When I disabled that trigger temporarly, I found that I could revert changes made to multiple portal records--definitely a useful behavior to keep in mind for future solutions!