Skip to main content
Submitted

LEFT KEEP support for Qlik adapter

  • July 10, 2017
  • 7 replies
  • 0 views

Forum|alt.badge.img

LEFT KEEP makes sure only the dimension values actually present in the fact table are kept in the dimension table for a Qlik app.

It would be good to have this supported in the modeller.

See also https://community.qlik.com/thread/39177

 

7 replies

An even better option would be to include the "WHERE EXISTS(Field)" option, since this will never create any duplicate values in Qlik.

Left Keep acts like a join. This is however, a much needed feature.


Forum|alt.badge.img
  • Known Participant
  • August 24, 2018

Are there plans to add this feature? 


Forum|alt.badge.img
  • Author
  • Known Participant
  • August 24, 2018

"I believe that we have several ways on the Business Unit and/or Data Warehouse side to achieve the goal for this feature request"

Could you please have someone draw up guidelines how to do this then? Currently I don't see an obvious alternative for this within the existing product, apart from funky scripting.


Forum|alt.badge.img
  • Author
  • Known Participant
  • August 24, 2018

1) In what direction does the relation need to be then? Because if it's from dimension to fact table, every fact with an unknown dimension is discarded, which shouldn't happen as users do want to see input errors appear from their side.

LEFT KEEP cleans the dimension table. So you're saying I need to make the relation from fact to dimension which doesn't make much sense and will surely break auto-relate in the OLAP model.

2) well yes it does since I need to create a view based on a join again. Might as well then just use the Qlik Sense data modeler directly if I need to script.

The strong thing of TimeXtender is essentially the graphical modelling and relationship creation. These suggested workarounds do the opposite.

 


Forum|alt.badge.img

I would like to once again stress the need for this feature on the semantic model layer. I come across the issue at least once a week.

Let me try to illustrate the impact:

* I have table with all inventory transactions of the company for all years (let's say 1999-2019) and all locations (let's say 5 locations), totalling 10 milion rows

* I have a calendar table and a location table, linking to the transaction table using a key field (location.id and date.id)

* I want to make a Qlik app where I am purely intrested in data for location A over the past 2 years.

* I can drag the location and date dimension tables into the model and add a filter for each that filters them to only include the correct dimension values.

* However, I cannot add a filter to the transaction fact table, because I cannot predict upfront what the values of location.id and date.id are for the years 2018 and 2019 and location A.

Without the where exists I am forced to push all +/- 10 milion rows to my Qlik app and I need to write set analysis expressions in all my visualisations to filter out the +/- 9.6 milion rows I don't need.

With a where exists function I don't need to write extra set analysis and I only push +/- 400k rows to Qlik...


  • New Participant
  • October 14, 2019

I totally agree with Lennaert van den Brink


Please-o-please add this feature to TX ASAP, so we can save ourselves huge (link-) tables for absolutely no good reason.