1 Reply Latest reply on Mar 19, 2013 8:47 AM by philmodjunk

    Portal Filtering Based Upon a Text ID

    EitanRude

      Title

      Portal Filtering Based Upon a Text ID

      Post

           Hi,

           I am very, very new to FileMaker and I'm trying to make a member database for a local pool/tennis club. I've been able to set it up and figure out the workings of FileMaker for the most part, including a member check-in function in which a seperate database stamps a member's first name and last name, as well as the time and date that they enter the club, all at the click of a button. The issue I'm having is that I want to use a portal function to display the dates and times of entry for specific members using a portal function to that external database. I've tried to set up the filtering numerous times and using a number of different calcuations, but altogether, FileMaker seems incapable of filtering this master record based upon first and last name. Any suggestions as to where I am going wrong are greatly appreciated. 

            

        • 1. Re: Portal Filtering Based Upon a Text ID
          philmodjunk

               Filtering by first and last name can certainly be done, but be careful. It's quite possible to have different members with identical first and last names. A member ID serial number assigned to each member record by your database may be very helpful in separating records for members with identical names. Another complicating factor is that people sometimes change their names.

               That said, the first step toward setting up a portal that filters by first and last names is to set up the correct relationship for your portal. Any filter you define will reduce the set of related records displayed in the portal to only those related records that can cause the filter expression to evaluate as True or as a number value other than zero.

               You might have this relationship:

               LayoutTableOccurrence::anyField X PortalTableOccurrence::anyField

               Using the X operator means that all the records in the portal's table will appear in the portal unless a filter is used to reduce the number of record shown.

               Then your filter expression might be:

               LayoutTableOccurrence::Firstname = PortalTableOccurrence::FirstName AND
               LayoutTableOccurrence::LastName = PortalTableOccurrence::LastName

               But you'll find that editing the Two fields shown to the left of = in the above expression does not automatically update what records appear in the portal unless a script performs this step:

               Refresh Windows [Flush cached join results]

               And this is a step that in many circumstances, can produce undesirable delays while updating your layout.

               That requirement can be eliminated if you use this relationship:

               LayoutTableOccurrence::Firstname X PortalTableOccurrence::anyField AND
               LayoutTableOccurrence::LastName X PortalTableOccurrence::andyField

               On the other hand, you can simply chose not to use a portal filter and just use this relationship:

               LayoutTableOccurrence::Firstname = PortalTableOccurrence::FirstName AND
               LayoutTableOccurrence::LastName = PortalTableOccurrence::LastName

               You may also be interested in approaches that use partial name matching in a portal as a way to search out records in your database: https://www.dropbox.com/s/0pm1gdqcfi2ndpv/EnhancedValueSelection.fp7