7 Replies Latest reply on Jan 24, 2017 12:05 PM by beverly

    New Guy - Totally Lost

    tolson

      I'm from the world of Access and I am having a tough time wrapping my head around FM. What I'm about to describe, I have it working in Access, but my employer wants it in FM instead.

       

      It's basically a self directed testing protocol. The user will have an interface with 5 buttons, each of them going to a specific topic. Each button has 5 questions sorted by "round" (there are 5 rounds) and "category" (5 categories). After the person answers all 6 questions in a category, they are automatically transferred out to the original interface. The user can also answer "x" amount of questions and manually return to the interface.

       

      If all 6 questions in a category have been answered, the button on the original interface disappears. What I would like to do is have a number field [hold] for each category that calculates a perform find (Round =1 Category =1 Used= 0 or 1 [depending on whether the question is still in the rotation]), then have the total for the "Used" field inserted in in another field so the button will hide based on the value of that find (Round 1 Category 1 Used =6 the button is hidden, if used is less than 6 the button remains).

       

      Conditional formatting only works on one button at a time. Ive uploaded pics of the interface and question screens and also the underlying table structure. I'm not asking anyone to do the work - I just need to be steered in the right direction. As I said, I can get this working in Access, but not Filemaker and I know the limitation is my knowledge and understanding of FM.

        • 1. Re: New Guy - Totally Lost
          philmodjunk
          Conditional formatting only works on one button at a time.

           

          This is not the case.

           

          In your first screen shot, I'd use either a list view or a portal so that I only actually have one button with a text field providing the label. This allows me to flexibly control the number of buttons by adding/removing records.

           

          Your data model looks generally OK, but I don't see any table where you can link specific answers to specific people. That may not be needed, but it often is for Survey or Questionnaire type solutions.

           

          But you really haven't told us where this process fails for you. All that you describe is readily doable in FileMaker.

           

          So break it down for us. Where exactly do you "get stuck" when setting this up?

           

          A few general "translation notes" from making the jump from MS Access to FileMaker:

           

          Layouts in FileMaker are roughly the same as a Form or Report in Access. However, the "unwritten SQL" for a Filemaker layout would look like this: SELECT * From TableOccurrenceName. There'd be no "WHERE" and no "ORDER BY" clauses. TableOccurrenceName is the name of one of the "boxes" on your relationship graph. (Joins are represented by the relationships spelled out in Manage | Relationships).

           

          To get the equivalent of "WHERE", you perform a find. Unlike Access, any user, unless you prevent it, can perform their own finds simply by putting the window into find mode and doing a kind of "Query by example" query of your database. Likewise, "ORDER BY" is accomplished by the Sort Records option and again just like Finds, ad hoc sorts may be done by the user as needed.

           

          You'll find value lists in FileMaker to be very primitive when compared to an Access Combo Box, but we often can get same functionality in FileMaker with the use of a selection portal placed inside a popover.

          • 2. Re: New Guy - Totally Lost
            tolson

            Thank you for the response.

             

            So are you saying that I could / should have a portal for each button? I

            was under the impression there could only be one portal on a layout.

            • 3. Re: New Guy - Totally Lost
              philmodjunk

              No, I was describing either a list view or a single portal where either each record in the list view or each row in the portal has just one button.

               

              But you can put many portals on the same layout.

              • 4. Re: New Guy - Totally Lost
                coherentkris

                tolson.

                FM paradigm is very different than Access.

                The relationships graph is NOT an ERD but is almost a graphical query engine.

                The objects on the relationships graph (table occurences) can be thought of as being similar to a view in SQL land.

                You can have many table occurrences bound to the same table.

                Layouts are bound to table occurrences on the relationships graph so everything is about context.

                You can have many portals on a layout.

                From a layout you have access to everything that the TO you are bound to can access via the relationships on the graph.

                 

                Welcome to FM and enjoy the steep end of the learning curve.

                • 5. Re: New Guy - Totally Lost
                  tolson

                  "Welcome to FM and enjoy the steep end of the learning curve."

                   

                  First laugh of the day - Thank You!

                  • 6. Re: New Guy - Totally Lost
                    philmodjunk

                    It's really not a steep learning curve for most. But developers used to SQL based systems have some "unlearning" to do and that steepens the curve as they keep reaching for a familiar tool in their tool box only to find that they have to use a completely different one to do the same thing in FileMaker.

                    • 7. Re: New Guy - Totally Lost
                      beverly

                      you might explore this thread (and the link).

                      New to FileMaker?

                      and welcome to the community!