1 Reply Latest reply on Apr 26, 2009 10:29 PM by obeechi

    Problems with Portals

    claddam

      Title

      Problems with Portals

      Post

      Hi there, I have a problem with a portal.

       

      I am making a portal to display related information to the current layout.

       

      Eg:

       

      Mr X has one page and Mrs X has another page. I am trying to put a portal to show who they are related to. So the relationship I have done is by their Surname. So it should display all records of the person with the same last name. But its not working.

       

      Should I create a relationship on something different? 

        • 1. Re: Problems with Portals
          obeechi
            

          Relationships should be generally based on serial numbers, though there trick situations where you'll have a different arrangement, like a 'saved' querry

           

          The key thing to remember is it is your responsibility to make sure native IDs are being echoed into fields in foreign tables. By native I mean unique, and in a Super table or parent table. By foreign I mean a table acting as a subtable or child to the first table (relative to our first table). By echo I mean a copy is made of an ID and stored in the foreign table.

           

          When using Filemaker portals, this is done for you, behind the scenes, but only if you select 'create relationships' in the 'Edit Relationship' dialog window (found when in the relationship graph, and you double click the relationship operator). Note that if you have other foreign ID fields in your child table (because a child can have an infinite number of parents or super tables, meaning super entities) you'll have to populate those fields via other means. 

           

          Other means would be, manually write in each foreign ID, which is not reasonable, or make use of a script with a Set Field step et. Or: 

           

          If you were to work from a child layout, and wish to assign a parent, then you can use a drop down list for that field. In this case, you're working in the opposite direction of a portal, and so wouldn't need to select 'create relationship' in the Edit Relationship dialogue box (unless you're using the portal elsewhere). To assign a parent record you need to store a copy of the parent ID into the field meant to hold this copy in the child table (where its considered to be a foreign field, which means it isn't required to be unique). To do this you'll need to create a value list. The value list will have the ID as the first shown, whereas the surname will be the second shown. Even though the surname is shown, it isn't stored, only the ID is stored, and a copy of it at that. AFTER, this has been done, THEN you can have a display of the surname in yet another field in the layout that is now showing the related field SURNAME (which is like peeking into the parent table from the child table, but only when they're already related or joined together). The surname can be adjacent to the ID (in and on the child layout) or it can even be placed directly on top of the ID field (but you'll want to set it to be 'not-enterable' or 'not-editable' in browse mode, AND you'll want the ID to be set to the same color as the background of your layout -- you, the user, want to see human names, but filemaker the database, wants to see nonsensical numbers)

           

          One mistake to watch out for, is when assigning parents in a child layout, you might have the correct value list, but are (mistakenly) trying to store the parents ID copy into a field based on the wrong table -- it must be the field set aside for the copy of the parents ID that is resident to the child table.