6 Replies Latest reply on Apr 2, 2017 8:08 AM by BruceRobertson

    How to display a current found set in a portal

    dburnham

      I am able to easily create a summary field, using the LIST option to have a field that is always instantly populated with a return-separated list of the values from a designated field. 

       

      I thought I could filter the portal to refer to that found set by using PatternCount, but when I do that, the portal takes forever to refresh.

      Here's what I am working with.

       

      Example:   the summary field "foundset" contains the following values for a field called ID:

           123

           456

           789

           234

           345

           890

       

      In the portal filter, I have specified   if ( PatternCount ( foundset ; ID )  > 0 ; True ; False )

        • 1. Re: How to display a current found set in a portal
          William-Porter

          Dennis,

           

          Get the IDs of the records in the found set into a global field, and use

          the global field as the left-hand match field for the relationship upon

          which the portal is based. I’ve always scripted this — looped through and

          “harvested” IDs but using a list summary field sounds like a clever way to

          do it and may be faster. (I’ll talk about this next week.)

           

          Will

          • 2. Re: How to display a current found set in a portal
            taylorsharpe

            If you do it with the portal filter, Dennis, then you have problems if your ID in the pattern count is a double or single digit number because it will show True if you have a 12 for both the array items 12 and 123 and 1234, 1212, etc.

             

            If you want to do the portal filter, then do this:

             

                 If ( PatternCount ( ¶ & foundest & ¶ ; ¶ & ID ¶ ) > 0 ; True ; False )

             

            If you have large found sets, Will's idea with a join thru the global field could be a good idea too.

            • 3. Re: How to display a current found set in a portal
              William-Porter

              Will's idea "could" be a good idea even with small found sets.

              1 of 1 people found this helpful
              • 4. Re: How to display a current found set in a portal
                taylorsharpe

                William-Porter wrote:

                 

                Will's idea "could" be a good idea even with small found sets.

                 

                I think you should have a speed test at next week's FMPUG Dallas Chapter meeting you are leading, doing it both ways!  And if you do that, compare it to a SQL call and virtual list instead. 

                • 5. Re: How to display a current found set in a portal
                  BruceRobertson

                  I think the filtered-portal approach should be abandoned here.

                   

                  What is the purpose of the original set of IDs stored in the field?

                  Is there some real point in using the filter? Why not just put the new found-set ID list into that field?

                  (As described by Will)

                  Is there a need to go back at some point to the the original contents of the field?

                  Displaying a found set in a portal has been common and relatively easy to do for a very long time.

                  It has become much easier now that we have the new, native, list-of summary function.

                   

                  One of many examples:

                  https://www.1-more-thing.com/master-detail-view/#english

                  1 of 1 people found this helpful
                  • 6. Re: How to display a current found set in a portal
                    BruceRobertson

                    Yet another point about the intersection of the two lists.

                    That is; the original stored list which you mention; and the found-set ID list.

                    Of course if what you really want is just to display the found set in the portal; then Will's suggestion of using a global field for this relation applies. Don't use a portal filter.

                     

                    If - for some reason - you need to find an intersection of values from the original stored list; and the found set; then this is exactly where the FilterValues function can be used to great advantage. Again, the resulting list should be popped into a global field and the portal should be based on that.