Bug report #3030
Query Builder in Properties produces "Query Failed"
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Jürgen Fischer | ||
| Category: | Vectors | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | All | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 13090 |
Description
I select vector Properties/Query Builder
and use the mouse to create a Query which
results on error at executing the query.
Tried several combinations with and without " and/or '
The same procedure works fine with the Query Builder
started from the Attribute Table.
Also, other users confirm that this problem is
not present under Windows
Agus
History
#1
Updated by Jürgen Fischer about 14 years ago
- Status changed from Open to Closed
- Resolution set to worksforme
The expression you enter in the attribute table (and field calculator) are search string expression, that are QGIS specific and are evaluated internally.
The expressions you enter in the vector properties are different and are provider specific. These are evaluated by the provider (or it's datasource).
E.g. unlike in search strings you have the opportunity to enter more complex where clauses for postgres and spatialite layers (eg. call postgis functions, exists clauses etc) and those might even be evaluated much quicker, other providers (like the delimited text provider) might not even support subset strings or the query options might be format specific (like in the OGR provider).
Also note that the provider specific options may vary with different versions of the datasource (ie. version of PostGIS/SpatiaLite/OGR/GDAL etc). That might be why you see different behaviour between Linux and Windows.
#2
Updated by alobo - about 14 years ago
- Status changed from Closed to Feedback
- Resolution deleted (
worksforme)
Jef,
1. I don not enter the expression "ID"='12' myself, it's written
by QGIS when I double click in the appropriate Fields, Operator and Value entries.
So, in any case, there is a bug because QGIS does not write the correct syntax.
2. Unfortunately, I had tried ID=12 (and tried again now) and get the same problem
Agus
#3
Updated by alobo - about 14 years ago
Furthermore, both ID=12 and "ID"='12' work
from Attribute Table/Advanced Search
Agus
#4
Updated by Jürgen Fischer about 14 years ago
Replying to [comment:3 alobo]:
Furthermore, both ID=12 and "ID"='12' work from Attribute Table/Advanced Search
Sure. The Query Builder produces valid expressions for search strings, but not necessarily valid expressions for (all) the providers.
#5
Updated by Jürgen Fischer about 14 years ago
Replying to [comment:4 jef]:
that is, for a provider subset string.
#6
Updated by alobo - about 14 years ago
I attach the shapefile set.
Do not understand "Which OGR version are you using?", specifically, which libraries
do you mean? I have what is installed along the Ubuntu binaries from
https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable for Karmic (9.10)
#7
Updated by Giovanni Manghi about 14 years ago
Also, other users confirm that this problem is
not present under Windows
I just tested your shapefile under Seven/qgis-trunk and I get the same error that shows under Linux/qgis-trunk.
The shape columns are all "real" datatypes: ID = 12 isn't supposed to work?
#8
Updated by alobo - about 14 years ago
Interesting,
This is what [email protected] finds in a win platform:
"Hello,
in the pdf a few screenshots to get a funtional query.
I have tested the query builder wiht all kind of fields (integer, decimal,
text) and all is fine.
Gerhard
"
This is why I said the problem was not on windows.
ID > 12, which for sure would be valid for real numbers, does not work either
Agus
#9
Updated by Jürgen Fischer about 14 years ago
- Status changed from Feedback to Closed
- Resolution set to upstream
Seems to be an OGR (vector part of GDAL) problem:
ogrinfo -sql "SELECT * FROM polsfl1_1000 WHERE ID=12" polsfl1_1000.shp
INFO: Open of @polsfl1_1000.shp'
using driver @ESRI Shapefile' successful.
ERROR 1: SQL: Unrecognised field name coords.x1.
Looks like the attributes with dots in the name are the actual problem for OGR (the query is the same as the one the OGR provider uses.
I see the same on Windows, so I suppose Gerhard didn't use that shape, when testing on Windows.
#10
Updated by alobo - about 14 years ago
Confirmed: renaming coords.x1 and coords.x2 to coordsx1 and coordsx2 solves the problem.
Has the problem been reported to OGR developers?
Shouldn't QGIS have a warning for attributes names including "." meanwhile?
Agus
#11
Updated by qgisviti - almost 14 years ago
- Resolution deleted (
upstream) - Status changed from Closed to Feedback
Replying to [comment:10 alobo]:
Confirmed: renaming coords.x1 and coords.x2 to coordsx1 and coordsx2 solves the problem.
Has the problem been reported to OGR developers?
Shouldn't QGIS have a warning for attributes names including "." meanwhile?Agus
I still have problem with query builder in properties even if the name of columns doesn't have any dots. My field name is "NDVI" and when I use Qgis, I double click in the appropriate Fields, Operator and Value entries in qgis and it's written "NDVI">=0.06: the error "The subset string could not be set" is returned.
It works well from Attribute Table/Advanced? Search
So the problem may be more than dots in name of fields...
#12
Updated by qgisviti - almost 14 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed
Replying to [comment:11 qgisviti]:
Replying to [comment:10 alobo]:
Confirmed: renaming coords.x1 and coords.x2 to coordsx1 and coordsx2 solves the problem.
Has the problem been reported to OGR developers?
Shouldn't QGIS have a warning for attributes names including "." meanwhile?Agus
I still have problem with query builder in properties even if the name of columns doesn't have any dots. My field name is "NDVI" and when I use Qgis, I double click in the appropriate Fields, Operator and Value entries in qgis and it's written "NDVI">=0.06: the error "The subset string could not be set" is returned.
It works well from Attribute Table/Advanced? Search
So the problem may be more than dots in name of fields...
Ok...I'm sorry. I just understand that it must be no field with dot in the shapefile for query works. So Jef was rigth, "Looks like the attributes with dots in the name are the actual problem for OGR". Just be careful to change all names of shp and not just the name of the field you do query on.