Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I've posted the question on App Development forum, but it looks like a bug to me, so I am re-posting it here:
Handling [dash] and [single quote] by search objects
The version used is 11.20 SR10.
Will appreciate comments/suggestions.
Best regards,
Vladimir
Maybe it's related to Search - But what shall you find?
- Marcus
Hi Vladimir,
I think Marcus is rigth here. You're using the textsearch, which doesn't treat the ASCII-Code in that kind. E.g., if you search for lower characters, you find the upper characters too, but, if you search for '=index(Name,chr(39))' you will get the expected result.
Best regards
Sven
Sven,
Yes, this approach (using Index()) works fine, but I have serious doubts that my clients will be happy and willing to learn an ASCII codes table....
Especially because that this issue exists for chr(39) and chr(45) characters only...
Will use your suggestion as a workaround, but I hope that the issue will be resolved at some point.
Best Regards,
Vladimir
Maybe there are ways to optimize this workaround with some kind of ascii translation:
And also putting this in a variable-function for an easier usage like:
vSearch:
=index($1, chr(ord($2)))
Unfortunately seems this not to work for single-quotes but maybe there are further possibilties to get this to run like in this posting: https://community.qlik.com/blogs/qlikviewdesignblog/2015/06/08/escape-sequences#comment-33547 but in a first try it didn't work with a count-expression with a search set analysis but maybe hic had further ideas.
- Marcus
Hi Vladimir,
you will only need the ASCII code in the case of the single-quote.Otherwise it is sufficient to write "=index(Name,'-')".
And of course you could fill a bug report and if you do so, please let us know, whether it has been accepted.
Best regards
Sven
It took a while, but I've got a response from Qlik Support:
____________________________________________________________________
According to bug# QLIK-14849 and QLIK- 15675 both describe this behavior is working as design ( not a great design in my opinion), he is what R&D has explain about it:
"When you do global search for E and get a match on a word with É, the search suggestion will change the input line to É. The list of matches may contain words with either E or É.
Just as E and É sorts at the same position in all locales, hyphen and single quote sorts at the same position. Other punctuation sign (e.g. double quote, dot, plus) have higher and different sorting values, and these will not match each other, but hyphen and single quote happens to share search values."
I understand, hyphen and single quotes, are different character and the product should take it as different characters. For that I am going to reach the product manager team to look at this one more time, maybe (no guarantees) that we can make this better or at least documented so for future references and avoid any confusion.
____________________________________________________________________
Regards,
Vladimir