jason.michaelides wrote:1a) - that work, thanks. Unfortunately it's not practical as there are thousands of job titles and CTRL-clicking on the hundreds that contain "marketing" won't go down well with the users.
Fair enough. Is it possible to simply organize the information better by adding new fields? For instance, a marketing flag, or a Job_Type field with value 'marketing'? If so, it's trivial to select the 'marketing' and 'digital' values, or to select Y for the marketing and digital flags. That may not be practical, of course.
jason.michaelides wrote:1b) - couldn't get this to work at all. Not in the search box of the list box, nor in a search object. Works in a chart calculated dimension but not as an easy search. Any ideas? I'm using v9sp6
Works for me in list boxes and multi-boxes. Doesn't seem to work in search boxes. Look for "advanced search" in the help text for more information. I'm on v9SR5, but I doubt that's the problem.
jason.michaelides wrote:2) I'm afraid I can't make heads nor tails of these documents! It's 11pm here right now so I'll give it another go tomorrow but I'm really not sure I'll follow what's going on. Can you provide a brief overview?
TestOR5 takes advantage of the fact that QlikView's behavior in a SINGLE list box is OR. So it simply puts every field and every value of every field you care about in ONE list box. Each of these values is connected to the ID of the records that have that value for that field. So if you select values from two different fields, you'll get all of the IDs that either connect to. So you get OR across multiple fields.
TestOR6 is more complicted. It loads every possible combination of fields. So look at ID 1 for instance. It has every possible combination of values except for A=N, B=Y and C=Y. It doesn't have THAT row because it's the exact opposite of the actual values. The result of this massive combination of fields is that if you select a value for one, every possible value for the others is still allowed, and aren't constrained by your first selection. So if you select a value of Y for field A, it no longer matters what is in fields B and C. ID 1 WILL be returned.
It's impractical for a couple reasons. First, for anything more than a trivial example like this, the table would be massive. It would probably never load. Second, it isn't very user-friendly. Any field that doesn't have a selection made in it means that ALL values are allowed for that field. And if you're doing an OR with every possible value for some field, then you haven't really narrowed down your list at all. The only way to do that is to make SOME selection for EVERY field. And that's ridiculous except for maybe some very rare very specific requirement. What you really need is a way to select nothing, and have that be the default. No such luck.
So I really can't suggest TestOR6, and in hindsight probably shouldn't have included it.
Not sure I can really suggest TestOR5 either, but at least you could actually do the load, and when you select something, it stops allowing every value for every other field. Might be better than nothing, even if it isn't good.
.png "Luminary Alumni"){kind=icon}
