8 Replies Latest reply on Aug 31, 2015 9:55 AM by tays01s

    Portal: Scroll field list longer than portal

    tays01s

      Just trying again re. old thread: http://forums.filemaker.com/posts/0a60489b77

       

      I've got a portal in which I want to show 5 columns of 50 fields. Those 250 fields are from 1 records because it's easier to keep synchronisation between them and 2 of the columns rely on calculations from 2 of the other columns. So the suggestion of having separate records instead of fields in the above thread would seem awkward.

       

      Problem: I like to display say 15 fields in the portal but be able to scroll to the rest. But of course a portal  wants to display the full record.

        • 1. Re: Portal: Scroll field list longer than portal
          Mike_Mitchell

          250 fields in one record is a red flag for something being wrong with the data model. Perhaps if you gave us a more concrete description of what you're trying to accomplish, we can suggest an alternative to achieve your goal.

          • 2. Re: Portal: Scroll field list longer than portal
            erolst

            tays01s wrote:

            Just trying again re. old thread: http://forums.filemaker.com/posts/0a60489b77

             

            I've got a portal in which I want to show 5 columns of 50 fields. Those 250 fields are from 1 records because it's easier to keep synchronisation between them and 2 of the columns rely on calculations from 2 of the other columns. So the suggestion of having separate records instead of fields in the above thread would seem awkward.

             

            I suggest you re-read that thread; don't sacrifice a proper data model for layout considerations.

             

            In the long run you'll notice that an entity with 250 fields is awkward to handle. What does your solution manage, anyway?

             

            That being said: you could use two portals with different field sets and switch between them by hiding/displaying either one.

            • 3. Re: Portal: Scroll field list longer than portal
              tays01s

              More info:

              1. I need to present data on 50 nutrients in terms of: Requirement, Prescription and Input.

              2. For the latter 2 I also need to present % of Requirement.

              All are currently in my 'IO' (input/output) table.

               

              Hide/display: Yes, I intend to have such a script so that Prescription and Input are present as either input or %.

               

              I see your point re. the v. large number of fields. However, this is a function of needing to represent 50 nutrients per 'set'.

               

              Does this help explain the problme?

              • 4. Re: Portal: Scroll field list longer than portal
                Mike_Mitchell

                Yes. And every time you add or change a nutrient, you have to change your data structure. Very bad practice.

                 

                You should have a data table where each record is a nutrient. Then have a set of 50 records corresponding to whatever parent you're trying to present. There are a variety of methods for doing this. But your system will eventually become unmanageable if you start off with a poor data model.

                • 5. Re: Portal: Scroll field list longer than portal
                  tays01s

                  Have I got this right, I'd have 1 table for say 'Protein' and this table would have say 5 fields: Requirement, Prescription, Input and %P, %I?

                   

                  How would I handle having 1 table per nutrient x 50? ie. I accept it may provide flexibility but I'm not sure how to efficiently implement.

                  • 6. Re: Portal: Scroll field list longer than portal
                    erolst

                    You have a table where every record is a different protein with its inherent attributes.

                     

                    The structure you're looking for is probably something like basically this:

                     

                    ParentTable --< ProteinForParent >-- Protein

                     

                    where Protein holds your Proteins definitions.

                     

                    The proteins that make up a ParentRecord are “copied” into the join table (more to the point, its primary key is), along with the ParentRecord's primary key. These two keys state: this protein appears in this Parent, and the attributes in the join table describe this in detail.

                     

                    Together, the related join table records represent the “recipe” for a ParentRecord record; a list of “ingredients”, each with, say, an individual quantity (and other attributes pertinent to their appearance in this recipe).

                     

                    Display them in a portal and configure away.

                     

                    Reversely, you can see for each protein in which ParentRecord it appears; and the join table allows you to perform all kinds of statistical analyses.

                    • 7. Re: Portal: Scroll field list longer than portal
                      tays01s

                      1. So regarding: ParentTable --< ProteinForParent >-- Protein

                      I'd have relationships:

                      ParentTable --< ProteinForParent >-- Protein

                      ParentTable --< EnergyForParent >-- Energy

                      ParentTable --< FatForParent >-- Fat     etc for 50 nutrient parameters? Or would the join table be a single table eg. 'NutrientforParent'?

                       

                      2. NutrientforParent: This would copy over the Requirement, Prescription, Input and %'s etc ?

                       

                      3. I'd put a portal from 'NutrientforParent' on Parent?

                      • 8. Re: Portal: Scroll field list longer than portal
                        tays01s

                        Pondering 'erolst's' info further:

                        - Are you saying have: Parent < Join > Nutrient?

                        - Copy the 50 nutrient names to Join? And when you say 'copy', how do you?

                        - Copy the attributes (they are all calculated values) from Nutrient to Join?

                        - Would I then not use a portal of these values into a parent layout?

                         

                        Some other queries. Because all the values required to regenerate these values are kept as records elsewhere I only need to view the above. So, can these records be temporary, ie. they re-calc everytime 'upstream' values change?