Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We have implemented the QlikView Join, Keep and Concatenate in QvScriptor, a new revolutionary tool, able to generate QlikView script from visual schema.
We have written this small doc for the help file and we thing interesting to share it with the community as we found only partial explanations about the methods.
The QlikView script functions JOIN, KEEP and CONCATENATE can sometimes be used to solve the same problem, but there are important differences that should be understood.
Examine the sample tables below. Note that they share one common field name, "Key".
Also note that Table1 has a Key value "3" that is not present in Table2 and that Table2 has a key 4 that is not present in Table1.
Table1 | Table2 | |||
Key | A | Key | C | |
1 | A1 | 1 | C1 | |
2 | A2 | 2 | C2 | |
3 | A3 | |||
4 | C4 |
JOIN will combine rows where the Key value matches.
Here's what the merged table will look like after the different join methods.
Note that QlikView merge the two tables after a Join.
Note: The explicit join keyword (= Outer Join) in QlikView script language performs a full join of the two tables. The result is one table. In many cases such joins will result in very large tables. One of the main features of QlikView is its ability to make associations between tables instead of joining them, which greatly reduces memory usage, increases processing speed and offers enormous flexibility. Explicit joins should therefore be generally avoided in QlikView scripts. The keep functionality was designed to reduce the number of cases where you need to use explicit joins
OUTER JOIN (Table1) | LEFT JOIN (Table1) | ||||||
Key | A | C | Key | A | C | ||
1 | A1 | C1 | 1 | A1 | C1 | ||
2 | A2 | C2 | 2 | A2 | C2 | ||
3 | A3 | - | 3 | A3 | - | ||
4 | - | C4 |
RIGHT JOIN (Table1) | INNER JOIN (Table1) | |||||
Key | A | C | Key | A | C | |
1 | A1 | C1 | 1 | A1 | C1 | |
2 | A2 | C2 | 2 | A2 | C2 | |
4 | - | C4 |
The keep prefix between two load or select statements has the effect of reducing one or both of the two tables before they are stored in QlikView, based on the intersection of table data. The keep keyword must always be preceded by one of the prefixes inner,left or right. The selection of records from the tables is made in the same way as in a corresponding join.
However, the two tables are not joined and will be stored in QlikView as two separately named tables.
LEFT KEEP | ||||
Table1 | Table2 | |||
Key | A | Key | C | |
1 | A1 | 1 | C1 | |
2 | A2 | 2 | C2 | |
3 | A3 | 3 | - | |
RIGHT KEEP | ||||
Table1 | Table2 | |||
Key | A | Key | C | |
1 | A1 | 1 | C1 | |
2 | A2 | 2 | C2 | |
4 | - | 4 | C4 |
INNER KEEP | ||||
Table1 | Table2 | |||
Key | A | Key | C | |
1 | A1 | 1 | C1 | |
2 | A2 | 2 | C2 | |
Now let's look at Concatenate. Concatenate appends the rows of one table to another. Concatenate never merges any rows. The number of rows in a concatenated table is always the sum of the rows from the two input tables. Here's what our sample data will look like after Concatenate.
CONCATENATE (Table1) LOAD * RESIDENT Table2;
Key | A | C |
1 | A1 | |
1 | C1 | |
2 | A2 | |
2 | C2 | |
3 | A3 | |
4 | C4 |
Rows with like Key values are not merged together. The rows from Table2 are simply appended to Table1. Because the tables have different fields, rows will have null values for the fields from the "other" table.
QsGen Team
Excelente, muy bien explicado, tenía dudas de esto; pero, con tu explicación quedé satisfecho.
Gracias.
Great overview. Thanks!
Hi,
this is a good overview - but there is one important issue it doesn't address:
The example for the LEFT JOIN - right now, I am only interested in that particular one and I have only looked at that - is a simple one: There is a unique key in table2 and so the LEFT JOIN works as you would expect, the number of records in the result matches the nr. of records in the original table1.
If, however, the key used in table2 is not unique, then the LEFT JOIN will, as I understand it, retain all those records from table2 that match the key in table1, so the result will have more records than the original table1.
Depending on the business application, this might be correct - it can be compared to a WHERE EXISTS clause and if the multiple records add a required detail level, that is all right, but if what you want is an additional info that should be there only once for every key_in_table1, then a non-unique key in your table2 represents an issue.
Very good explanation..It helps a lot ..Thank you.
Very good explanation..It helps a lot ..Thank you.
Very good explanation..It helps a lot ..Thank you.
Very good explanation..It helps a lot ..Thank you.
Good one..
Awesome post. Bookmarked