Query Builder in Properties produces "Query Failed"

[alobo]

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

"ID"='12' in "subset" of a shape file produced an message box with "An error occured when executing the query", while ID=12 finds a matching feature in the attribute table.

Agus

[jef]

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.

For me using ID=2 on a shape file with an integer ID attribute works fine.

[alobo]

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

[alobo]

Furthermore, both ID=12 and "ID"='12' work from Attribute Table/Advanced Search

Agus

[jef]

Replying to 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.

BTW "ID"='2' also works here for a shape file. Do you get any output on the terminal? Which OGR version are you using? Also please include a shape file that isn't queryable for you.

[jef]

Replying to jef:

BTW "ID"='2' also works here for a shape file.

that is, for a provider subset string.

[alobo]

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)

[lutra]

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?

[alobo]

Interesting, This is what gerhard@… 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

[jef]

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.

[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

[qgisviti]

Replying to 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...

[qgisviti]

Replying to qgisviti:

Replying to 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.