1 2 3 Previous Next 30 Replies Latest reply on Feb 17, 2010 11:43 AM by SCOPe

    Radio Button History

    SCOPe

      Title

      Radio Button History

      Post

       


      FileMaker Pro Advanced 10.0v1
      Windows XP Professional Service Pack 3

      Database Details:
      FileMaker Server 10
      24 Databases
      67 Average Connected Users
      Majority Connected Through Citrix Xenapp

       

      Question:

      I have many radio buttons on a layout that I need to keep the history of what status they were in on certain dates, and be able to display the status.

       

      For example:

       

       

       

       

       

       

      Missing, Incomplete, & Invalid is one radio set

      Resolved is another radio set

       

      I need to keep the history of if Missing, Incomplete, or Invalid is checked....based on certain dates.

       

       

       

      Current thought of setup:

       

      I have a seperate table that holds records for these critierias:

      Each Record Contains:

      Date, Field for each criteria(Critieria 1, 2, 3)

       

      Where I am stuck is based on which date I search by, setting the layouts radio selection to display that history...

       

      I'll take whatever thoughts/suggestions I can get.

       

      I know it's a bit confusing...let me know if I need to explain it a little more.





        • 1. Re: Radio Button History
          philmodjunk
            

          A separate table sounds like the right idea.

           

          Do you know how to set up a portal? A scrolling portal can show you the whole history in a scrolling list.

           

          You can sort the portal by date so that the most recent entry is listed first.

          • 2. Re: Radio Button History
            SCOPe
               Sounds good, I'm just hoping setting 60ish fields at once doesn't lag....  :smileysurprised:
            • 3. Re: Radio Button History
              philmodjunk
                 Why would you need to set so many all at once? I assumed you would do this a single portal row at a time spaced out over the "life" of the record.
              • 4. Re: Radio Button History
                SCOPe
                   A single row in this database contains 60+ fields that needs to be set. It works well though.
                • 5. Re: Radio Button History
                  DLW-BPEX
                    

                  Phil,

                   

                  You said: "You can sort the portal by date so that the most recent entry is listed first."

                   

                  I've been working with a very similar issue, doing just that. Works well, although I was wondering: Since the child records can be sorted either in the portal or through the relationship, is there an advantage of one method over the other?

                   

                  Thank you.

                  David 

                  • 6. Re: Radio Button History
                    philmodjunk
                      

                    No advantages that I can think of, just differences in application. If I want a portal sorted the same way on several layouts with the same multiple field sort, I can set it at the relationship level and know that all the portals will sort in exactly the same way.

                     

                    Sorting a relationship also affects:

                     

                    First and last functions

                    Which record supplies data to a related field outside a portal when there are multiple matching records (Same as first function)

                    How records are sorted when Go To Related record is used to bring up a found set of records.

                    • 7. Re: Radio Button History
                      DLW-BPEX
                        

                      Good information.

                      In addition to displaying the records in reverse chronological order in the portal, I also want to plot y-values against x-time. Using a looping script to generate Google chart data, it sounds like a relationship-level sort may be better in this case.

                       

                      However, I am not seeing any difference in Previous and Next (using FM's built-in navigation "notebook" arrows) whether relationship-based sort is on or off. Nor any difference with nav buttons assigned First, Previous, Next, Last. It looks like both portal sort and relationship sort affect the order displayed in the portal, but not the unsorted order on the child layout in Browse mode. Dates remain in the order they were entered, which was not chronological.

                       

                      Does that sound right? 

                      • 8. Re: Radio Button History
                        philmodjunk
                           First, next, previous, Last will all change to a different record based on the current order of records in your current found set. Whether sorted, unsorted; via relationship, script or selecting sort from the record menu; the resulting order of records in the found set is what controls their behavior.
                        • 9. Re: Radio Button History
                          LaRetta_1
                            

                          SCOPe wrote:
                          A single row in this database contains 60+ fields that needs to be set. It works well though.

                          Scope, I must tell you that having 60 'like' fields breaks good relational design.  Those 60 fields should be related records.  If you change your structure now, it will save you great heartache later.


                          • 10. Re: Radio Button History
                            SCOPe
                              

                            LaRetta wrote:

                            SCOPe wrote:
                            A single row in this database contains 60+ fields that needs to be set. It works well though.

                            Scope, I must tell you that having 60 'like' fields breaks good relational design.  Those 60 fields should be related records.  If you change your structure now, it will save you great heartache later.


                            Can you elaborate more on this? What's wrong with a record with many fields? What would you recommend? Do you have any articles/links that might help me with what your explaining?



                            • 11. Re: Radio Button History
                              LaRetta_1
                                

                              I shall try to explain some of it ...

                               

                              Reason #1:  If you wish to find all records marked as Incomplete, you will have to do this:

                               

                              Enter Find Mode []

                              Set Field [ your radiobutton field1 ; "Incomplete" ]

                              New Record/Request

                              Set Field [ Your radiobutton field2 ; "Incomplete" ]

                              New record/Request

                              ... and repeat for 58 more times before you can perform your find

                               

                              Reason #2:  You wish to count how many of each selection were made.  You cannot create a sub-summary report which groups by words as:

                               

                              Missing (25 records)

                              Record Number 1

                              Record Number 44

                              Record Number 55

                              ... etc

                               

                              Incomplete (14 records)

                              Record Number 2

                              Record Number 14

                              Record Number 62

                              ... and so forth

                               

                              Reason #3: If you decide to add another category, you must add another field instead of simply creating another record (as it should be).  This means that you, or another developer must enter Define Fields.  And if you have to create calculations and finds which counts, sums, or otherwise manipulates all of these fields (see Reason #1 & #2) then you will also have to adjust every calculation (all 60 of them) and adjust every Find script.

                               

                              Reason #4: It is very time-consuming, inefficient and limited.

                               

                              It is not just my preference ... it is known relational theory and I would just hate to see you go that route.  You haven't explained what these fields represent but 60 'like' fields (which simply rate via radio button) sends off red flags.  It is possible that there is good reason but it is very rare that it would be the best choice. 

                              • 12. Re: Radio Button History
                                SCOPe
                                  

                                Interesting...How would you go about setting this up the right way for a relational database as your defining them as separate records?

                                • 13. Re: Radio Button History
                                  SCOPe
                                    

                                  LaRetta wrote:

                                   

                                  It is not just my preference ... it is known relational theory and I would just hate to see you go that route.  You haven't explained what these fields represent but 60 'like' fields (which simply rate via radio button) sends off red flags.  It is possible that there is good reason but it is very rare that it would be the best choice. 


                                  To explain a little more about these fields. I'm setting up a QA type of system where a "packet" is being graded almost. There are 29 critieria fields that are getting "graded" and each of these fields can be graded as "Incomplete", "Invalid" or "Missing". Also each field can be set to "Resolved" but I need to know if it was Incomplete, Invalid, or Missing when it's been set to Resolved later so I thought I would make that a seperate radio family. Therefore making it about 60ish something fields.

                                   

                                  I will be needing to do reports on all this information like you described above too.


                                  • 14. Re: Radio Button History
                                    philmodjunk
                                       You can replace your fields with a portal of 60 records where one record = 1 criteria category for the current record. If Portal is a new concept, there's a fairly decent explanation in filemaker help if you search under that term.
                                    1 2 3 Previous Next