it give the first appearance of the data i.e. if 024 present in first table it will give 024 and exclude 24 ,if it is 24 present in first table it give 24 and exclude 024.
Qlikview attempts to recognise data based on the first (or first few) record(s) - in a similar way to Excel. If the record looks like a number (and both 024 and 24 look like numbers), the QV will load the data as numbers, and clearly 024 and 24 are the same number. The Text() function at the first load point ensures that the data is retrieved as text - the leading 0 will be preserved and the two IDs will be different.
This is why is is usually considered bad practice to use leading zeroes and leading spaces in code/id/category fields.
Logic will get you from a to b. Imagination will take you everywhere. - A Einstein
One possible explanation could be that it was actually O24 stored before 5th Oct 2015 and someone changed it into 024 on the 6th of October... It is really hard to guess at what happened in your source systems at a point back in time.
But there are certainly pitfalls of data quality with the load script in this area. Especially ID's that are really not numeric but they look like it. That is they come from character columns in databases and should actually be treated as pure text values in QlikView. If you don't do that you potenially get corrupt data. I am not kidding. It will interpret separate distinct differently character/text ID's as the same value based on the numeric interpretation. This is usually not at all what you want.
That is why it is adamant that you wrap all such columns in the Text()-function while loading them to tell QlikView to keep them as Text and only Text. If not some or all values - depending on whether they look like numbers or not - will be Dual values and not Text values.
That will lead to all sorts of Quality issues:
1. Incorrect counts
2. Missing IDs (often product IDs) - as some distinct IDs will be treated as the same
3. Sorting is quite different when it is dual than the sorting is with pure Text values.
In enterprise implementation I tell my customers ALWAYS to wrap columns by using Text() when doing a load from any source when it comes to character columns. If you don't you might be lucky and not run into the problem. But it is a sure land mine that the system sooner or later will run into. And it is a particular NASTY problem as it is not so easy to detect. Just a few IDs will silently disappear and be counted and aggregated in the wrong way.
So a correct approach would be to have a load statement like this:
Datatable:
LOAD
Text( ID ) AS ID,
Text( ProductCode ) AS ProductCode,
Text( Vendor ) AS Vendor,
Num( Quantity ) AS Quantity
;
SQL
SELECT ....... ;
Yes I know it is "boring" to have to write Text() always for every character column that will be turned into a field. But if you don't it will lead to data quality issues unless you are extremely lucky.
That is why I made a routine that automatically generate the load script for the first tier of import of data so my customers and I don't need to remember this stuff.
