Non-Hierarchical dimensions possible?

[#1]

I would like to have multiple dimensions (multiple fields) which are shown side-by-side rather than Hierarchically. Typically you have dimensions such as State and City where Cities are a sub-set of States. I have multiple-response questions (Like which stores have you shopped in the last month) so there is 1 boolean field per store and I would like to show the stores side-by-side. I can't do this in expressions because I'm already using a different multiple-response category there. Is this possible in QlikView?

[johnw]

I don't actually understand the question, but although QlikView supports various types of hierarchies, by default, the dimensions are non-hierarchical. All dimensions can be referenced independently and shown side by side.

If that wasn't helpful due to my lack of understanding, consider posting some simplified data and a chart showing how you want that data to look. That would help me a lot to understand what you're asking.

[#3]

Thanks John.

A real-world example would be that 1 want to show a table with 2 axes. On the 1st axis (rows) I want to show items like Households with Computer, Households with Children, Households with Satellite TV, etc. while on the 2nd axes (columns) I want to show "Purchased Product A, Purchased Product B, Purchased Product C, etc.

Since all of these values potentially have overlap I have to use a field for each one. On one axis I can simply use Expressions but I believe I'll need to use Dimensions for the other one. When I add dimensions to a Pivot Table it tries to layer or stack them rather than simply showing them side-by-side, hence my dilema. Perhaps I'm missing something simple.

[johnw]

Yeah, I believe a pivot table always displays hierarchically. It would be nice if it gave a display option to repeat the values like a straight table, but I don't see a way to do that. One solution is close to what you were saying - make a separate expression for each product sold, but then use a straight table instead of a pivot table. See attached. It's just inconvenient from a development and maintenance point of view, particularly if your products change. Hopefully someone will think of a better approach.