Calculated Dimension in Pivot on Server

[#1]

Hi,

We are currently experiencing an issue with a pivot table when moving from my local client onto a server environment.

The pivot table is constructed with 3 dimensions and one of these is a calculated dimension which for the example I have replaced with simply the Date() function. The calculated dimension is used as the pivot.

There is a single expression summing a counter flag. No set analysis.

The Pivot table works fine on my local machine but when viewed on the server, in the client or via accesspoint, the object results in the error 'Allocated memory exceeded'.

The pivot table calc. time is only 6968 and it only uses 26KB of memory. Both clients are licensed and running version 11.20 (x64). local client is on SR7 and the server SR5.

If the calculated dimension is removed and replaced with just the field value the pivot table loads fine.

This is the pivot table with the calculated dimension and the pivot table working without pivoting on the date field.

If the Date(DateWE) dimension in dragged to the top right to create a pivot on the dimension the 'allocated memory exceeded' error is received.

If the date() function is removed from the calculated dimension the object is loaded fine.

This final image is the pivot table working correctly with the calculated dimension as the pivot on my local machine and the calculated dimension limiting to a rolling 12 weeks. If this is deployed to the server and viewed in the QV server client it will not load and the error message display almost instantly, no long load time, server has multiple CPUS and 256GB ram running at avg 50% utilization so plenty of resource available.

Can this be caused by windows OS or hardware related? Or actual QV config/setup over application design?

Any help or guidance is greatly appreciated as its turning out to be a puzzler!

Cheers,

Joe

[Anonymous]

Hi

Have you tried creating the Date(DateWE) in the script? And also check the allowed max calculation time on the server. This shouldn't be a problem as i think default is 60s but if this has been changed on the server then it might be the cause however I cant really se why it should be turned down that low. Check on both the Server Setup and on document level.

[#3]

Hi Nick,

Many thanks for your response.

We have determined that this in fact a bug when moving from an app developed in 11.2 SR7 and then onto a server running 11.2 SR5.

Thanks again.