12 Replies Latest reply on May 12, 2017 6:33 PM by Licorice

    Survey question and managing in Data/Control




      I'm in the process of using my FM12 pro advanced to frame up a questionnaire. Going ok re that but have struck a couple of hurdles that I'm needing some help on. It concerns 'how to display a couple of questions in my layout that are tricky'.


      First tricky question to display re fields is the following. Tried to capture and paste into this dialogue box but without luck ....so here goes the 'manual' version:


      Q12. To what extent does she/he help you in the following activities:

                                                  None       A little       Some       A lot       Totally

      - working your cattle?                0            1              2             3            4

      - doing the book keeping?                     <same>

      - weed control?                                      <same>

      - other (name)                                       <same> 


      So my question is: Is there some way to show these under the 'Data/Control style' as a group under one question......or am I looking at doing a question with radio buttons (say) for each option (e.g. working your cattle? etc)?


      Second 'tricky' question:


      Q22. How many cattle do you have?               Type              Number

      - Females older than 3 years?

      - Females 13 months to 3 years old?

      - Bulls older than 2 years old?

      - Bulls younger than 2 years old?


      Again perhaps a similar question: How to design in the layout - under one question ...or a separate question for each type of cattle?


      Looking forward to your reply on this as I am at a stalemate until this is resolved.




        • 1. Re: Survey question and managing in Data/Control

          First we need to understand how you've set up your tables and relationships.


          For a single survey, I recommend a minimum of:




          For multiple surveys, you'd add: Surveys----<Questions to the above


          Questions::__pkQuestionID = Responses::_fkQuestionID
          Respondants::__pkRespondantID = Responses::_fkRespondantID


          This makes every question an individual record and every response to a  question by a respondant (person taking the survey) an individual record plus a table of records with one record for reach respondant.


          Is that what you have set up?


          This structure then makes much of what you want to do here pretty straight forward. So please confirm your set up before we take a closer look at how you might set up a user interface for people to use to log their responses to your survey questions.

          • 2. Re: Survey question and managing in Data/Control

            This is what I have for one client:



            When a form is selected for a student, the appropriate questions & answer choices, if any, is then CREATED in another table. This is really Questions and the "answers" have a field for selection or entry for each question. This I call Responses. It gets the formID, questionID responseID (primary key for this table), studentID




            This is very flexible in allowing the questions and answer selections to be created, deleted or edited.

            Because the 'surveys' change, there is no direct relationship between the setup form and the completed form with responses, even though they would have the same formID. The same formIDs can be used to compare questions to see how a form changes over time.



            • 3. Re: Survey question and managing in Data/Control

              Hi Phil and Beverly. Firstly thank you both for your replies. They send me one clear message and that is I have a LOT of extra reading to do to begin to build in your advice. So for now it is 'back to the books'. Hopefully I'll emerge slightly more informed than I currently am! Thank you both once again.

              • 4. Re: Survey question and managing in Data/Control

                I set up something similar by following your more detailed instructions in another thread, which I'm unable to locate right now.


                I've set up the 3 tables you describe above.  I've set up a layout that uses a portal to record the responses. The questions are generated by a script which is activated by a button.


                My problem is that the questions can be edited by the respondent.  I cannot figure how to set the permissions so they can read the question field but cannot change it.  I've been going Manage -> Security and playing around with the permissions sets, but nothing seems to work correctly.


                If the permissions are set up for the user as:

                Records: Custom: Questions           yes     -     -     -     all

                                              Respondents      yes     yes     yes     -     all

                                              Responses          yes     yes     yes     -     limited (fk_Question = view only)

                then the Questions are not generated in the portal. I really don't understand that at all. It seems with view only set, they should still be able to read the field. Therefore I have to make the fk_Question = modifiable, which gives the respondent the ability to edit the question field.


                I tried to accomplish the same thing through the layout inspector by unchecking everything under Field Entry but then the longer questions get cut off, and a scroll bar doesn't do any good because the user can't click on it when nothing is checked in Field Entry.


                I'm stumped.

                • 5. Re: Survey question and managing in Data/Control

                  Why would fk_Question be accessible to the user at all? Why is it on the layout where they can modify it?


                  It must be modifiable so that new Response records can be created and linked to a given question, but thus need not mean that it is exposed on the layout where the user can edit the field.

                  • 6. Re: Survey question and managing in Data/Control

                    Thanks for responding Phil,


                    I don't see how I can expose it on the layout without it being editable.  Disabling field entry in browse mode disables the ability to view the entire question.


                    Maybe it's the way I have the tables set up? Let me clarify. My solution is more of a dynamic survey where the questions may change.


                    The Questions table has the fields: pk_Question.ID (auto-enter serial); pk_Question (text with the question); Active (1 or 0 - to set it as a current question.


                    The Responses table has the fields: fk_respondant.ID; fk_Question.ID; Response ( 1 or 0 - this is actually a checklist); Response Time (timestamp).


                    The script finds all the Active = 1 questions then populates the portal on the layout with the found set. Two fields are in the portal displaying records from the Response Table.  Response, which is a checkbox with the field sized to where the "1" is not visible and fk_Question, which is the Question text.

                    • 7. Re: Survey question and managing in Data/Control

                      I don't see how I can expose it on the layout without it being editable.  Disabling field entry in browse mode disables the ability to view the entire question.

                      To repeat: WHY is it exposed on a layout that the user can access? There's no need to do that and thus this need not be an issue.

                      • 8. Re: Survey question and managing in Data/Control

                        I don't follow you. The question is on the layout so they know what they are responding to.

                        • 9. Re: Survey question and managing in Data/Control

                          You don't need the fk_Question.ID field to show the question. The question is not the fk_Question.ID field. It's just the match field to the question table where a text field holds the question. This field can be placed on your layout to display the question. It can be placed as either a merge match field or field behavior can be used to block browse mode access.


                          But if fk_Question.ID shows the actual question, you have something very wrong in your design.

                          • 10. Re: Survey question and managing in Data/Control

                            So I tried several other things (scripts, relationships, new layouts, etc) to get this to work. Nothing did, so I went back to the set-up and permissions described above and now it works fine.  The only thing I can think of is that somehow the permissions were not being applied, saved, or shared correctly.  I was logging the user out and back in whenever I changed the permissions and had started even closing the solution out completely, so I'm at a loss as to what actually went wrong.

                            • 11. Re: Survey question and managing in Data/Control

                              this does not change the fact that a field named fk_Question.ID should not need to be present on a layout used to record responses to the question. Nor should it be used to display the actual question as that is data in a different field.

                              • 12. Re: Survey question and managing in Data/Control

                                Hi Alan,


                                What you are trying to do with the survey is not a simple plug-and-play action. It requires a good understanding of how FileMaker manages relationships between tables, layout design and script functionality for the version of FileMaker you are using.


                                Surveys are a species by themselves…

                                The first thing you need to think about is how you want to structure the questions.

                                Multiple choice versus open, or both in the same survey. Whatever you choose, it will impact how you word the questions and how the solution must be built. You can make it as complex or simple as you like.


                                For example, your question 22 asks for more than one response: you not only want to know if the customer has a certain category of cattle, but you also want a free comment that allows them to enter the type and the total number in that category. Ideally, this should be split out over at least 2 questions. You also need to think about how you want to process and display the answers.


                                I am suggesting you initially build a "mother survey" solution that can handle both the creation of more than one survey, and more than one answering sets.


                                One part of the solution is where you create your base surveys and questions. This is administrator access only.

                                The other part is where you create the actual survey for your customer. Also administrator access only. You, in other words.


                                Once you have created a satisfying questionnaire for a survey, you export it into a user interface file that you can send to them. And in that file you can simply add a generic user account that handles the user’s basic privileges. Basically, the only fields that they need to be able to access are the open comment (if present) and the answer field that will contain their multiple choice option. And off they go. They send it back to you and you make sure you have a script to receive the results into your “mother survey questionnaire table” so that you can display the results of all respondents in that solution. Which is a project in itself…


                                What I have attached is an example file created in FMP13 that you should be able to open and use in your FMP12 environment. It was built using the Anchor-Buoy approach. If you are not familiar with it, it is worth your time looking it up and familiarising yourself with it. It is, in my humble opinion, the simplest way to construct your graph and it will be helpful for you in learning to work with relationships in FileMaker.


                                I realise this solution is just one of the possible approaches to cater to your issues. Also, I have not concentrated on a pretty user interface design. This is just about the general approach.


                                When you open it, you enter a customer name. This is in preparation of the scenario that you will need to log which customer entered which questionnaire. Then you choose from available surveys in the file and create the questionnaire for that survey.  After that, you have to write code for the transfer of the questionnaire to another file that can be sent to the customer. The file is prepared with an additional table just in case you need to log multiple surveys for the same customer, but I am not using it in this particular version of the file. But you can build on that yourself.


                                In layout mode you will see several approaches to allow or deny access to fields, which was the topic you opened this post with.


                                Have a look in the feedback (FB) layout and you will see a mix of:

                                -using a merge field (that looks like a title and is not a field that anyone can enter anything in, not even you as the programmer)

                                -using a field for which access in browse and/or find is blocked

                                -using a hiding condition on certain fields to create questions with dynamic answering option styles; a field that is hidden does not exist for FileMaker. Is not displayed, cannot be accessed.

                                And of course, as Phil pointed out, fields that are not on a layout cannot be edited or accessed (unless you write scripts to write data into them...)

                                FileMaker's layouts do not have to contain all fields in a table. The layout is like a window to the table, that only shows certain elements of what needs to be visible of that table.


                                I would not recommend to use the access privileges to direct access at field level. Although this is certainly possible in the privilege sets of your solution, it seems like a bit of overkill and unnecessary complexity at this stage.


                                I hope this helps and I wish you good luck building this into a good looking and efficient user interface! Let me know if you have any additional questions.