3 Replies Latest reply on Apr 15, 2014 9:28 AM by philmodjunk

    BUG? FMP 12: Portal Filter work with literal search but not global variable?!

    Pstone

      Title

      BUG? FMP 12: Portal Filter work with literal search but not global variable?!

      Post

           Very simply put, I have a portal pointing to database "X" and told to FILTER based on matching X:TextFieldName = "TEST" (literally as in I spelled it out in quotes), it works. All records in X:TextFieldName = "TEST" are listed.

           When I change the filter to X:TextFieldName = $$global_var and set $$global_var = "TEST" I get completely wrong results. Am I missing something here? I have data viewer visible showing that $$global_var = "TEST" and I have even tried to set manually.

           Bug?

        • 1. Re: BUG? FMP 12: Portal Filter work with literal search but not global variable?!
          philmodjunk

               Changes to the value of the global variable will not automatically update what you see in the portal. Follow the change to the variable's value with this script step:

               Refresh Window [flush cached join results]

               and see if you get what you want in the portal.

               If that works, I can describe an alternative method using a global field instead of a variable that will not need this rather drastic method of getting the portal to update.

          • 2. Re: BUG? FMP 12: Portal Filter work with literal search but not global variable?!
            Pstone

                 Nailed it Phil. I can also see how then a global field would work instead. I /have/ been using those in other situations but thought this would work as well. This is fine in a pinch as this is just to print a rental agreement and is not done heavily throughout the use of the DB.

            • 3. Re: BUG? FMP 12: Portal Filter work with literal search but not global variable?!
              philmodjunk

                   With a global field, you can modify the portal's relationship so that you can still use the filter, but not need any refresh window [flush...] step to update it.

                   But since your portal filter is not specifying anything that really needs to be put in a filter, I'd just add the global field as an added match field in most cases.

                   (But if your portal filter expression were to use a more sophisticated expression than just matching exact values via the = operator, you can make the following change and then your portal filter will update automatically when the global field's value is changed:

                   Say your portal filter expression now is:

                   LayoutTable::PrimaryKey = PortalTable::ForeignKey

                   Change it to:

                   LayoutTable::PrimaryKey = PortalTable::ForeignKey AND
                   LayoutTable::globalField X PortalTable::anyfieldyouwanthere

                   Adding that global field in with the X operator won't change what records show as related, but it forces the portal filter to update each time the value of the global field is updated.