Skip to main content
Announcements
Qlik Connect 2025: 3 days of full immersion in data, analytics, and AI. May 13-15 | Orlando, FL: Learn More
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Understanding Join, Keep and Concatenate

QVScriptor_Full_Small.png

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

Type of Joins:

JOIN will combine rows where the Key value matches.

  • The keyword OUTER will also retain rows that do not match rows in the other table.
  • The keyword LEFT will retain rows from the left table but only matching rows from the right table
  • The keyword RIGHT will retain rows from the right table but only matching rows from the left table
  • The keyword INNER will retain rows matching the left table and right table

Joins

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

A2 C2







4 - C4



Keep

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
KeyA
KeyC
1A1
1C1
2A2
2C2
3A3
3-





RIGHT KEEP


Table1

Table2
KeyA
KeyC
1A1
1C1
2A2
2C2





4-
4C4

INNER KEEP


Table1

Table2
KeyA
KeyC
1A1
1C1
2A2
2C2










Concatenate

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

49 Replies
Not applicable
Author

Excelente, muy bien explicado, tenía dudas de esto; pero, con tu explicación quedé satisfecho.

Gracias.

Not applicable
Author

Great overview. Thanks!

datanibbler
Champion
Champion

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.

Not applicable
Author

Very good explanation..It helps a lot ..Thank you.

Not applicable
Author

Very good explanation..It helps a lot ..Thank you.

Not applicable
Author

Very good explanation..It helps a lot ..Thank you.

Not applicable
Author

Very good explanation..It helps a lot ..Thank you.

gainkarthi
Partner - Specialist
Partner - Specialist

Good one..

techvarun
Specialist II
Specialist II

Awesome post. Bookmarked