8 Replies Latest reply on Jul 21, 2011 4:16 PM by philmodjunk

    Endless Portal Row loop

    RedL

      Title

      Endless Portal Row loop

      Post

      I use the following scripts to set fields.  There is one set field script within loop only.  The "Ext after last" does not work.  It keeps looping.  And I can see new empty portal row increase one by one on each loop after the last row on the portal.

      Go to Portal Row [Select;First]
      Loop
      Set field ...
      Go to Portal Row [Select;Next;Exit after last]
      End Loop

        • 1. Re: Endless Portal Row loop
          philmodjunk

          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]
          Loop
                 Set field ...
                 Exit Loop If [$Rowcount = Get (ActivePortalRowNumber )]
                 Go to Portal Row [Select;Next;]
          End Loop

          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.

          • 2. Re: Endless Portal Row loop
            RedL

            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.

            • 3. Re: Endless Portal Row loop
              philmodjunk

              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?

              • 4. Re: Endless Portal Row loop
                RedL

                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.

                • 5. Re: Endless Portal Row loop
                  philmodjunk

                  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.

                  • 6. Re: Endless Portal Row loop
                    philmodjunk

                    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...

                    • 7. Re: Endless Portal Row loop
                      RedL

                      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.

                      • 8. Re: Endless Portal Row loop
                        philmodjunk

                        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!