wernbrenk wrote:I prefer using flags instead of set analysis.
Create Field: YTD_Flag in your script. Assign value ='1' when the line qualifies a YTD. In your expression use sum(sales * YTD_Flag).
This will return the SUM(Sales) where YTD_Flag=1 and null when YTD_Flag<>'1'
This is much simpler and I believe improves performance of you charts as well.
I'm a fan of flags too. But you can also write the expression like this:
sum({<YTD_Flag={1}>} sales)
Which isn't particularly complicated. As for comparative performance, that's an ongoing debate and can depend on your data model. That said, my own testing shows that set analysis is faster, and I also have this quote from a senior support technician:
"* SA SHOULD be faster than IF because of the way SA are using the selection engine (whereas IF has to aggregate all data).
* Flag multiplication will almost always be slower because it costs more, AND needs to aggregate all data.
...
Now, the reason to why I am using a capital "SHOULD" all the time, is that during the tests, we discovered that code involved in SA and the calculation of certain data structures and in certain scenarios could be greatly enhanced; something that also has been done now. We are in our tests seeing a great increase of speed in SA expressions, and actually in many cases besides that. Some had to do with parallelism issues, others did not. We've done tests on other large customer live data, and in those cases we're now sometimes seeing more than a 50% increase in SA expression calculation speed. Others have also noticed this decrease in performance, just as you did. Although these changes are going to be present in SR1 of v9, some others are further in the future. But SR1 is going to be much faster than 7119 in some cases, that's for sure."
None of this addresses the original question, of course. I haven't played with browser deployment, but if you're convinced that set analysis is the problem, I'd frankly report it to QlikTech. The browser deployments SHOULD work properly, after all.
