Filters based on Database for Contents

Question

We are now preparing a second wave for our study, and we want to have some questions personalised based on e.g., sociodemographic data like gender from the previous wave. I have imported the old data via Database for contents, and have formed new variables from them via put(). However, filters based on this variables do not work. Since there are quite a lot of these filters, and they can be copied from previous variables, it would be very helpful if we didn't have to code all of them in PHP on each page.

This is the code on my first page:
$key = caseSerial();
$data = dbGet($key);
put('X202',$data[0],true);

The filter on the X202 variable determines if a question on the second page should be hidden. But the question is displayed regardless of X202 value.

Is it possible to use filters in such a case? Or would you recommend some other way?

Thank you in advance

Comments

With "filters do not work" you refer to the filters that can be defined in the user interface? Typically, if you have multiple filters, PHP is more convenient then defining all of them separately in the user interface, because ou can simply copy&paste them?!

---

We already have all the filters written in specific variables (i.e., when creating a question, defined like filter questions, e.g., if the answer is 2, than another question on a some of the following pages won't be shown) so rewriting them in PHP would be a lot of work. Just coping the variable and renaming it is much easier, if possible.
I did not understand from your answer: Can a variable that is not itself displayed in the questionnaire, but has a value given via dbGet() and put() be used as a filter question?
I am not sure if the filtering is not working because of some error on my side, or because it is not posssible.

---

You can - currently - not define any filters in a question of type "internal variable". We can see, if we can implement this until 10th November, if that was helpful for you. Was it?

> Can a variable that is not itself displayed in the questionnaire, but has a value given via dbGet() and put() be used as a filter question?

Only with PHP at the moment.

> We already have all the filters written in specific variables

What exactly do you mean by that? That the filters have been defined in selection questions? Because you will not be able to copy those filters from the selection questions to the internal variable questions.

---

Thank you for reply. However, I have not formed the variable as an internal variable, because I  have used argument TRUE in put(). So the values are saved in a regular variable (I have checked this in the Collected Data - once I go to the next page, the values of the varriables inputed by put() on the previous page appear in the Collected data). However, the filters based on those valued do not activate on this or later pages.
Thank you also for your kind offer, but we were hoping to start sooner.

Answer 1

We recommend to be careful with putting data into "normal" variables by using put(.., .., true), because there is a substantial risk of overwriting data. We still have implemented this option to allow for specific situations. If you are sure, you do not overwrite other data, that may be one.

Actually, we did not consider using this for filters, but it's an interesting idea!

However, the filters based on those valued do not activate on this or later pages.

The filters become active when the responses for the variables are read. One sledge hammer workaround would be to actually include the question, but hide it:

put('AB01', 3, true);
html('<div style="display: none">');
question('AB01');
html('</div>');

This should work without unintended effect. Please give it a try.

We will in the meantime check, if it's possible to trigger the filter-evaluation when a value is set via put(). But I cannot promise that this will be possible before mid of November.

Comments

Thank you for your reply! Now I understand what happenned in my case.
I'm happy this has led to a new idea for you. In the meantime, we have decided to repeat the question normally and explain why we are repeating the question.

---

Alright - good for me to know that there's no pressure to implement that feature at the moment.