3 Replies Latest reply on Aug 5, 2014 1:03 PM by philmodjunk

    Portal Filtering and Case Statements

    dave317yyc

      Title

      Portal Filtering and Case Statements

      Post

           Good Day, 

           I am hosting some filemaker databases on Filemaker Server 13.  I run Filemaker Pro 13 to create my layouts, etc.  I use Filemaker Go to access my apps/databases from an ipad.

           I have built an app that is working on well on the server, but when it is accessed from the ipads the portal filtering is EXTREMELY slow.  Can anyone offer a better way of doing this?

           Basically I have a player list.  The player list is shown in a portal under the TEAM layout, and there is a few different filters available for displaying data in the portal.  Currently I have a bunch of CASE statements combined with AND statements for filtering portal results.  I use the following but it is very slow when accessing the data through the WAN, and even pretty slow going over local wifi. 

           What i dont understand is if i display the data in a LIST that is not a portal, and use perform find and constrain find to filter the list, the performance is exponentially faster.  It is more ideal for me to use a portal based on how this app works but if i need to use a list i guess i will figure out a way to do that.

           Please look at my portal filter below and let me know if you have any suggestions.

            

           (TeamList::Rank > Teams::rankStartFilter)
           and
           (Case(Teams::posFilter="IDP-ALL";(PlayerList::Pos="DB" or PlayerList::Pos="LB") ;Teams::posFilter="ALL";True;Teams::posFilter=PlayerList::Pos))
           and
           (Case(Teams::teamFilter="ALL";True;Teams::teamFilter=PlayerList::Team))
           and
           (Case(Teams::availFilter="ALL";True;Teams::availFilter=TeamList::Avail))
           and
           (Case(Teams::dhFilter="0";True;Teams::dhFilter=TeamList::DH))
           and
           (Case(Teams::myTeamFilter="0";True;Teams::myTeamFilter=TeamList::ownerTeamSN))
           and
           (Case(Teams::injFilter="0";True;Teams::injFilter=TeamList::Injured))

        • 1. Re: Portal Filtering and Case Statements
          philmodjunk

               For iphones and iPads, I'd use a list view instead of a filtered portal. You can put controls in a header or footer that drive the needed scripted find to pull up the desired list.

               Portal filtering just layers many more calculations on top of each other (the filter expression has to be individually evaluated for each and every related record) and this can be painfully slow when using the slower connection and processor speeds of an iOS device.

          • 2. Re: Portal Filtering and Case Statements
            dave317yyc

                 Thanks for the quick reply.  As mentioned, I can make a list work.  WHat is the best way to have the list show only the filtered data?  Have a script (that runs perform finds and constrain finds) run everytime the window is loaded or refreshed or is there a better way to do this?

                  

                 Example my TeamList tabnle has a list of ALL players but I want only the players to display that are part of a certain TEAMID, like all players with teamID 9007.

            • 3. Re: Portal Filtering and Case Statements
              philmodjunk

                   Don't see that it makes much difference from a performance stand point as long as all your search criteria is specified for indexed fields. What works best from a usability standpoint is key as there are a number of different options for how the user might specify the search criteria. Here's a thread that provides some scripted find examples you might review as a source of ideas: Scripted Find Examples

                   If any of your criteria need to be specified in an unindexed field--such as a calculation field that references data in a related record or a global field, then it's faster to perform a regular find with criteria only specified in the indexed fields, then return to find mode specify the criteria for unindexed fields and constrain the found set.