This feature lets you quickly validate the accuracy of your survey, group, or question. It is available via the QA button.
The Survey Logic File shows everything that you specified for each question (e.g. name, text, help, conditions/relevance, validation rules, defaults, sub-questions, answers) in a convenient tabular format. It highlights any errors, and lets you click on the question and group IDs (or variables used within equations) to open new browser tabs to edit those questions or groups. This makes it easy to quickly edit any errors and refresh the logic file to confirm the accuracy of the survey before activating it.
The display is also designed to be be readable by researchers and study sponsors so that they can validate the accuracy of the survey design and logic. Show logic file update the cache for all expression for active survey.
It includes the following columns:
Rows are color coded as follows:
Answers have an additional attribute in the Relevance column
At the top of the page, there is a summary message. If all is well, it will say "No syntax errors detected in this survey", or "This group" or "This question", "by itself, does not contain any syntax errors". Otherwise, it will say "X questions have syntax errors that need to be corrected".
Each question that has syntax errors will be color-coded red in the leftmost column (e.g. Q-1). The following errors are common:
Here are many good examples of using syntax highligting.
Here is an example of a survey that has errors:
The following types of warnings and errors are present:
The variable name will be color-coded in red and surrounded by a red line. If you hover your mouse over the variable name, it will say "Undefined variable".
Starting in 1.92, the preferred naming of question codes is [a-Z][0-9a-Z_]* - meaning it must start with a letter, and can contain letters, numbers, or underscores. However, for backwards compatibility, we are are only flagging invalid variable names via a warning for now. We expect to give the option to disallow those old variable names in the future, since many of the new features (along with proper SPSS / R export) require unique and properly formatted question codes.
These warnings appear as a pink line surrounding the variable name in the Name [ID] column. If you hover the mouse over the variable name, you will see this message:
Clicking on the link for the variable name opens up a new browser tab in which you can fix the error. You can have as many tabs open as you want, so you can simply click on all of the errors, fix and save them all, then re-run the Show Logic File report to confirm that you have fixed all of the errors.
All of the syntax-highlighted text has embedded tool-tips, and is clickable.
The following examples are taken from the Expression Manager Sample Surveys. You can find screen-shots of running surveys, explanations, and downloads on that page.
Here are screen shots of this example.
This is the Question-Reorder view of the Body Mass Index calculation. You can see the relevance equations (which are after the variable name, within square brackets - like  for weight, and [!is_empty(height) && !is_empty(weight)]) for BMI. You can also see the tailored text of the questions.
The logic file provides additional information, including question type, and lists of sub-questions and answer options, plus all question attributes.
Note that the (VALIDATION: ) section is automatically generated for you from the question attributes you have selected. This lets you see what validation logic is being applied, but you never have to specify or edit that validation logic directly.
This has a good example of nested if() statements to generate the weight_status.
Here are screen shots of this example.
This example shows the sub-question validation logic that is automatically generated when you use array_filter and array_filter_exclude. This example also shows how you can substitute the tailored "Other" value (the answer for Q02_other is Q01_other).
Q05 in this example shows simultaneous use of array_filter and array_filter_exclude on Q01 and Q02, respectively. This is part of how this example demonstrates cascading array_filter capabilities. Note that one of the main reasons for showing the question and sub-question level VALIDATION criteria is to help ensure you have not made any typos in specifying the array_filter or array_filter_exclude variable names (or in case you use different variable names for your list of filtered sub-questions). If you have such typos, you all of the invalid variable names will appear in red indicating that they are undefined, letting you quickly fix the problem.
This example demonstrates dynamic, cascading relevance logic to control display of question visibility. You can download this example here.
All questions starting with Q-20 (age) have a relevance equation. Q-22 (yearsMarried) also has a validation equation which uses the max_num_value_n advanced question attribute, but passes it an equation (age-5) rather than a fixed number.
Also note that questions kid1-kid3 are mandatory. However, if the question is not relevant, the mandatory requirement is ignored (which makes sense, since why would you force someone to answer an irrelevant question). These questions can be considered "conditionally mandatory".
This example shows how group-level relevance appears in the logic file. Here are screen shots of the working demo.
As you can see, the group-level relevance equation (cohabs > 1 && p1_rel != "") appear in the grey Person 2 row for G-2.
You may also notice that all of the questions are mandatory. However, if the group is irrelevant, so are all of its questions, so those questions are only truly mandatory if the group is relevant.
Additionally, note that the TIP messages are also automatically created for you. They are organized by value range (min/max), sum value range (min/max/equals), number of answers (min/max), etc. Sometimes you want to validate an answer range but don't want to display what might appear to be silly validation tips to the user. In such cases, you can use the hide_tip advanced question option (as in this case, to avoid telling the user that the age must be between 0 and 115 unless they try to enter a bad value).
This demo shows that although LimeSurvey 1.92 now fully supports use of comma as the radix (decimal) separator at run-time, you must still use a decimal as the radix separator at design-time (e.g. when specifying min/max values in advanced question attributes). The working example is found here.
Also, remember, the VALIDATION logic is created for you automatically from the advanced question attributes. The equations can look overwhelming, but you don't need to worry about them.