And the data size is >2GB? Sounds like you could achieve a size reduction by reducing the granularity of the data. Do you really need all the detail? I would investigate how to consolidate the data to the level of detail required.
Having said that, 2GB is not an exceptionally large amount of data for QV application, but you would need to have enough RAM. If your users are never going to drill to the lowest level in tables of hundreds of thousands to millions of rows, then an investment in extra RAM could be avoided.
Logic will get you from a to b. Imagination will take you everywhere. - A Einstein
Jonathan is right. This is not a huge dashboard. The problem is that any dashboard will feel like being monstrous and sluggish if there isn't an adequate server available to host it.
QlikView has one exceptional quality aside from the associative logic: it loads all data in RAM so that you and your users can have all data at your fingertips with lightning-fast response times (compared to querying a DB or another data source). But that won't work for one inch if the machine that is hosting your document(s) isn't really able to.
Installing sufficient RAM is the first and cheapest step in the scalability trajectory that QlikView supports. The next one may be adding Cores/CPUs. Or the other way around, depending on which resource is feeling an inordinate amount of pressure.
Are you displaying all the data in that pivot table... that will make it take 10 minutes to open. (To troubleshoot, delete all your sheet objects. It should open a LOT quicker.
Calculation condition is your friend in this case.
