Bug report #8129
Vector feature subset query uses ilike as like for non-latin letters
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||fixed|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||16960|
When using "FIELD" ilike '%ā%' in attribute table expression, it will give both results with "ā" and "Ā" letters as expected. Same expression in vector feature subset query will result only in results with "ā" letter and all entries with a capital letter are ignored => ilike works like ordinary like (tested also with a capital letter). It doesn't affect ascii-only letters.
QGIS master version 28efcda
Setting as a blocker, as it's hard to spot and thus might lead to incorrect results. Besides QGIS 2.0 finally should be encoding bug free as there have been too many releases with encoding problems. :(
#2 Updated by marisn - over 9 years ago
Jürgen Fischer wrote:
I suppose you're referring to OGR data sources. Does
ogrinfo -sql "select field from someshapefile where FIELD like '%ā%'" shapefile.shpwork for you? If it doesn't it's probably a OGR issue (btw. LIKE and ILIKE are both case-insensitive in OGR SQL).
Yes, you are right. It's a OGR issue. Seems that both LIKE and ILIKE are case sensitive (not case-insensitive as stated in OGR documentation) in OGR SQL. Still - leaving bug open as in the attribute table it works as expected and thus there's no reason why any reasonable enduser would expect that feature subset query should be different.
#3 Updated by Matthias Kuhn over 9 years ago
There is no real "fix" for that, because one is handled by OGR, the other one by QgsExpression.
A recent similar bug was closed as "wontfix"
I would propose to clearly state the fact, that the query is going to be handled by the dataprovider in the dialog.