Control Pivot Table dimension being used for "crosstable"

[Or]

Dear all,

I'm looking for a way to control the dimension being used as the left-to-right (row) dimension in a pivot table crosstable. For example, in the below sample, Year is the problem dimension.

Product - 2008 2009 2010

A 1000 2000 2500

B 2000 2300 1000

The issue I've been having is that pivot tables can cause extreme performance issues - and even QVS crashes - when they have too many members. This problem is compounded when you use cyclic groups, and a random click on the cycle arrow can switch from a small dimension to a large one. What I'm looking for is some sort of calculation condition stating that if the table would have more than N columns, it should not be calculated, or any alternative condition that would stop the chart from displaying when it has an impossibly-high number of columns.

Obviously, I can "force" this issue to some extent by avoiding cyclic groups with large elements in pivot tables, but even in a fairly basic pivot, a user can drag a regular dimension column into the crosstable area and generate a server-crashing pivot table - so I don't see any easy way to prevent this in the design.

Thanks in advance,

Or

[Oleg_Troyansky]

Or,

If you have to provide so much "freedom" to the end users, you might have to use calculation limits (instead of "Ignore limits" that we all prefer lately).Uncheck "Ignore Calculation Limits" in User Properties and then set Memory and Number of Cells limits for each Chart that might become too heavy.

"DASH"

[Or]

Oleg,

Thanks for the tip - I completely forgot we could use memory limits. I ran a quick test and this does seem to be helping.

The issue in question isn't so much that I'm allowing my users freedom, but rather that this freedom is inherent in QlikView. Some clever soul realized they could drag any field in a pivot table to create a crosstable, and by trial and error managed to set up an impossibly large matrix (1000x5000) which QVS did not like one bit. Since there's no setting that will keep users from doing this, I have to come up with an alternative way to prevent server performance issues caused by creative users.