Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
HI,
Thanks for all the help with IntervalMatch. I managed to put together this example of a slowly changing dimension. (The product Code remains the Same but the Product Name changes and we need to retain and report on History.)
Hope this helps others ...
ColinR
Hi ColinR,
First at all, thanks for the example.
I try to reproduce this example in my project and it doesn't work exactly like your example. The double relationship that the script creates in your example convert in a 'syn' relation in my example. I tried to copy-paste your script code in my script and create a 'syn' table too with exactly the same script code than yours.
It exists any flag to check this property?
Thanks in advance.
Xerx
I have the same question as Xerx has there been any resolution/response ?
Colin,
I have the same question as Xerx has there been any resolution/response about the syn key? ?
Miguel, after I looked closer I realized I was using the internal table view as opposed to the source table the syn is still there I just didn't see it at first and I couldnt see where it had been dropped in the code proper (because it was not). Thank you so much for your time I will review this example as well and see what I learn 🙂
You're welcome. For what is worth, synthetic keys are not so bad when they are done on purpose, and intervalmatch may be (may be not) one clear example for this. At the end of the day, what a synthetic key does is to create a composite key. I'm using some working datamodels where synthetic keys are wanted and performing fine, instead of renaming fields and create new fields.
Hey ColinR,
I've posted a solution to the shortcomings of your good example. Without any synthetic keys and support for multiple products 🙂
Have a look: http://guerrillabi.com/Slowly_Changing_Dimensions_QlikView