Bug report #8129
Vector feature subset query uses ilike as like for non-latin letters
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: | - | ||
| Category: | - | ||
| 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 |
Description
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. :(
Related issues
Associated revisions
context_help/function_help:
- remove en_US postfix
- remove translated files (translation were moved to ts files earlier)
- remove unused jQuery (python help doesn't use it anymore)
- change expression label in QgsQueryBuilder and add context help (partly fixes
#8129)
History
#1
Updated by Jürgen Fischer almost 11 years ago
I suppose you're referring to OGR data sources. Does ogrinfo -sql "select field from someshapefile where FIELD like '%ā%'" shapefile.shp work for you? If it doesn't it's probably a OGR issue (btw. LIKE and ILIKE are both case-insensitive in OGR SQL).
#2
Updated by marisn - almost 11 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 almost 11 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.
#4
Updated by Jürgen Fischer almost 11 years ago
- Resolution set to fixed
- Status changed from Open to Closed
documentation added in c6a4bb86a.
#5
Updated by marisn - over 10 years ago
OGR part of issue reported upstream: http://trac.osgeo.org/gdal/ticket/5132