Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Sunny, let me explain what I mean.
First: there is a contextual difference between long numbers being handled by an engine or an expression parser and long numbers (in text form) being (mis)treated by QlikView functions. For example, the long number that Gili used in the OP won't cause any problems when specified as a constant, because both the script engine and the expression evaluator are capable of stripping the leading zeroes. However, a QlikView function (like for example num#()) has a practical limit to the length of string numbers it can handle. That limit currently still stands at 14 digits. Gili's number has 18 digits.
Furthermore: QlikView functions are used all the time, whether you want it or not, whether you know it or not. There are explicit conversions functions like num() and num#() and there are implicit ones. Remember that - mainly for reasons of performance - QlikView will try to interprete every field value to see if it can store a value as a dual. String numbers that are longer than a certain number of digits will not be converted and will remain text-only values, even without specifying a format conversion function. For example, in an expression like [Input Field] * 1 QlikView will try to use the numerical part of the dual field to make the multiplication work. However, if the original value contained too many digits, there will not be any numerical value because the implicit conversion at LOAD time will have failed.
And one more: one of the most important steps during script execution is the LOADing of data from external sources. This data is very often available only in text form (except when reading Excel files) and implicit conversions will therefor be of utmost importance and will determine what type of data you will end up with.
A few examples will illustrate this:
Creating a text box with the expression =(000000000000002216 * 1) will display 2216. Perfect, the expression evaluator can handle too many digits and produce a numerical value Note that this is not an implicit/explicit conversion using functions. The parser does this.
Creating a text box with the expression =num(num#('000000000000002216'), '#0') will return ... NULL. Why is that? num#() is actually incapable of converting the otherwise perfectly legal string into a numerical value because the string is simply too long. num#() therefor returns the original text-only string, which the num() funciton cannot accept as a valid parameter. Result = NULL.
The same logic applies to scripts. Put the following two four statements in a script, reload and see what you get:
LET vConstMult = 000000000000002216 * 1;
LET vFuncConv = num(num#('000000000000002216'), '#0');
LET vNum14 = num(num#('00000000002216'), '#0');
LET vNum15 = num(num#('000000000002216'), '#0');
Of course, nobody will specify numbers with that many useless leading zeroes in an INLINE table or as string constants. But external sources may very well contain numbers that are formatted to carry more than 14 digits. In that case you'll have to devise your own technique to convert them to real numbers. That's what I mean with a "capacity limit". It has purely to do with what implicit and explicit conversion functions can handle when converting from one format to another.
Best,
Peter
