There are a number of prefixes in QlikView, that help you load and transform data. One of them is the Crosstable transformation.
Whenever you have a crosstable of data, the Crosstable prefix can be used to transform the data and create the desired fields. A crosstable is basically a matrix where one of the fields is displayed vertically and another is displayed horizontally. In the input table below you have one column per month and one row per product.
But if you want to analyze this data, it is much easier to have all numbers in one field and all months in another, i.e. in a three-column table. It is not very practical to have one column per month, since you want to use Month as dimension and Sum(Sales) as measure.
Enter the Crosstable prefix.
It converts the data to a table with one column for Month and another for Sales. Another way to express it is to say that it takes field names and converts these to field values. If you compare it to the Generic prefix, you will find that they in principle are each other’s inverses.
There are however a couple of things worth noting:
Usually the input data has only one column as qualifier field; as internal key (Product in the above example). But you can have several. If so, all qualifying fields must be listed before the attribute fields, and the third parameter to the Crosstable prefix must be used to define the number of qualifying fields.
It is not possible to have a preceding Load or a prefix in front of the Crosstable keyword. Auto-concatenate will however work.
The numeric interpretation will not work for the attribute fields. This means that if you have months as column headers, these will not be automatically interpreted. The work-around is to use the crosstable prefix to create a temporary table, and to run a second pass through it to make the interpretations:
Finally, if your source is a crosstable and you also want to display the data as a crosstable, it might be tempting to load the data as it is, without any transformation.
I strongly recommend that you don’t. A crosstable transformation simplifies everything and you can still display your data as a crosstable using a standard pivot table.
You can then use Year and MonthName as dimensions.
It's important to note that you can no do a preceding load directly onto a CROSSTABLE under any circumstances. It is rare that I do a CROSSTABLE without also using a temporary table.
I've got a multi-header crosstable file to import and it's proving to be quite tricky. I posted in the Community and was pointed to the multi_header_pivot_import.qvw example (https://community.qlik.com/docs/DOC-4527#start=25) but that script is intended for Qlikview and there seems to be a problem in Qlik Sense with filtering on a variable, which was explained thus:
Since Qlik Sense already had Standard mode disabled, I'm not sure what else can be done to get this script to work in Sense. Does anyone here have an idea of either how to get the script in the QVW file to work in Sense or can suggest a script that will work for transforming this data correctly?
Hi all I'm new to Qlik, and have the following question regarding crosstables. hic
I have this cross table in Excel:
Where the CurrentYear should aways refer to actual year, so 2018, which means PreviousYear would be equal to 2017, and PreviousYear2 to 2016. The values mean Sales.
How can I extract the years 2018, 2017 and 2016 to populate these 3 fields through scripting? The 2018 is a easy one, if we have the file named Sales2018. But what about for 2017 and 2016? And how should I maintain a file with this structure? Think for example 2019... Is the thought process exactly the same? An excel file Sales2019 has to be created, and the user only has to shift the values to the right?
I'm not quite sure how is that solution extracting the years 2018, 2017 and 2016. I have literally the fields named 'CurrentYear', 'PreviousYear' and 'PreviousYear2' in my columns, not the years. So, in the resident load, you are doing 2018 - 'PreviousYear'... See the problem?
But what about the best practice regarding the maintenance of this file structure? I mean, these are values for the current year and the prior 2 years. When a new year comes in, should the end user be left with the responsibility to manually shift the values to the right in the Excel file? Should he update only the 'Current Year' and leave me with the job to shift the values? If so, what changes in the script should I perform?
Basically what I'm asking is: how can I make this more error-free and easy to maintain in the client's side?