Is it possible to "apply" a set analysis expression as a normal selection?

[#1]

I have a number of set analysis expressions (in variables) that I use as data filters for a few fields, but it would be really useful to be able to re-use them as to apply the selection described in the set expressions as a normal selection.

I know about the "select in field" action, but aside from being a lot of work to define ~10+ selections on fields in this way for several controls, I'm not even sure it's technically possible to define some of the set expressions as a consecutive number of selections. Some of them involve reducing sets and selecting nulls by removing all data that has value in certain fields, which would translate into some "Select X in field Y" + "Select excluded in field Y", which doesn't work when there are more of these constructs since select excluded would select other data as well that has been excluded for another reason in an earlier select statement...

Any ideas? Macros? Other?

[sunny_talwar]

I am not sure I totally understand your question, but if you want to use certain selection as your default selection. I would make all the selection and use the 'Set Clear State' option to make those selections as default. So next time you change your selections and want to go back to your list of selections, you can click clear.

This may not be what you are looking for, but hey I am trying to help

Best,

S

[#3]

Hi, thanks, sorry but that's not what I meant...I guess a short, hopefully clearer, version of my question would be:

Is it possible in qlikview to somehow use a set analysis expression (set analysis syntax) to define and apply an app-wide ("normal") set of selections (the kind shown in a normal current selections-box)?

[marcus_sommer]

If you could apply these set analysis expressions as a valid search-expression to one or several fields like in this simply example:

Field: Monat

=only({< Monat = {"$(=num(month(today()-1)))"}>} Monat)

then you could save this as bookmark and used it a bookmark-box to easy call these selections.

- Marcus

[#5]

Thanks, I gave bookmarks a thought as well, and they are "selectable" through actions, but it would not look very good in the app if there already were a set of "weird" (for most users) bookmarks in the bookmark list used for "internal" purposes. Only a minor part of the users would use the selections in this particular case.

[marcus_sommer]

Maybe you could apply "personal bookmarks" for these few users and used the import/export-feature to implement the bookmarks.

- Marcus

[kuba_michalik · Accepted solution]

I feel I'm repeating what Marcus said, but if you use this as the search string in the "Select in field" action:

='=Only({$(yourSetAnalysisVariable)}fieldToSearch)'

you'll select only the values in fieldToSearch which are present in the set defined by the set analysis expression. Bookmarks are a tangential matter to that (nb, you can hide bookmarks from the dropdown menu - go into "More..." section, and uncheck "show" for them. Users can still find them if they dig, but if they do they are probably technical enough not to mind too much)

Keep in mind, though, that you can easily whip up a set analysis expression which will result in a set which is not achievable through normal listbox-clicking. You wouldn't be able to replicate something like this as selection in fields.

[chrismarlow]

My general rule of thumb is if I find I am trying too hard with expressions then I should look at the data model and see if I need to add something there that simplifies the expressions I then need. Obviously only helps if this something you are building/in control of rather than just consuming.

[#9]

Thanks! I tried but couldn't make that kind of expression work in the "select-in-field"-search string, but the error messages in QV...are not really informative often and even absent in this case...

That works as a solution to my problem, and yes, the selection is probably not easy, if even possible, to arrive at using the GUI but that was the purpose of the select-in-field part from the start; to give the user something easy to click to apply the selection that is behind a certain calculation. If they understand what pops up in the "current selection", then great, otherwise they can at least make the selection now.

Anyway, thanks!

[#10]

It may be possible with some work, but the idea is that users should be able to do advanced selections on any field in the datamodel, which reflect the datamodel of the source system to a large degree, and if creating those kinds of "supercalculated" tables in the datamodel, I'm afraid it would confuse many users, where what they see comes from and how it relates to the source system...but thanks for the suggestion!