Hello @Jazzman ,   Since nested aggregate expressions are not possible you could possibly work around this using aggregated data sources and then data joins.    Best regards, Petri   ... View more

Hello @Renan_Crepaldi ,   With the data structure you have, personally I don't think it's doable with any out-of-the-box chart or custom build graph. The way I see it, you have two options to achieve this: Adjust the data structure If you have one of the newer versions of VA then you could use Data-Driven Content and any JavaScript charting framework to create this.   Best regards, Petri ... View more

Hello @Stephanvd    Performance is a broad subject and I typically survey three things: Client-side performance i.e. number and type of objects to render. Often slow reports have many pages and each page has a high number of chart object. Are all the objects truly necessary? If there's many pages (+6) then can you split the report into two or more reports and create links between reports? Design performance i.e. amount of data manipulation actions done on presentation layer. Interactions, filters, display rules, custom calculations, hierarchies, parameters, geo maps, custom sort and custom categories all trigger data manipulation actions which means more time is spend. Considering performance it's a good idea to try to minimize the number of actions that need to be done to the data on the report. Is there calculations and row-level transformations that you can move to the data preparation layer? You could also try creating separate tables for control objects, such as Drop-down box and List object, and then Join the data on the fly on the report. If you have a long table then for every Drop-down box it needs to go through the whole column to get the distinct category values. Producing a separate short table for control objects takes this burden away and even though it now has to perform a Join on the report it's often faster than using a single table especially if the table is long. Server-side performance i.e. structure, type and size of the source data. Eliminate any unnecessary columns from source data on the LASR server. Reduce character field lengths and decimal places in numeric data if possible. Avoid using compressed data tables, views and star schemas if there is performance issues. Also each server has it's own limits mostly based on the number of servers, CPUs and memory. Generally it's a very good thing to be aware of the server limits and f.ex. not exceeding the recommended max amount of data that can be loaded into SAS plus not exceeding the recommended max size of the largest individual data table to be loaded into SAS. Also number of heavy and light users are important. I would say making separate tables might be a very good thing for performance. On the negative side it will make the overall administration a little bit more burdensome and increase memory consumption on server.   Best regards, Petri ... View more

Hello @Thanuja ,   I suggest you try a Needle Plot and adjust Line thickness  (from Options > Needle Plot) to somewhere between 3 and 6 to get a preferred look. You could also do this with Vector Plot, but this is a more straightforward approach. I hope this helps.   Best regards, Petri           ... View more