OpenFileGDB data source returns wrong values for SELECT DISTINCT queries

[ndawson]

(original bug report here: ​http://hub.qgis.org/issues/14407 )

It seems there's a bug in the OpenFileGDB driver which results in values from the wrong field being returned when a SELECT DISTINCT query is used with a single field which is NOT the first field in a layer. The resultant values from OGR_F_GetFieldAsString are always values from the first field in the layer.

Strangely, I'm not able to reproduce this when running the query using ogrinfo, but I can reproduce it when running the query with OGR_DS_ExecuteSQL (ie see ​https://github.com/qgis/QGIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L2426)

I've attached a dataset which demonstrates this issue.

[ndawson]

Apologies - I cannot get the dataset small enough to attach here. It's available at ​http://hub.qgis.org/attachments/9721/qgis_bugreport_14407.gdb.rar

[Even Rouault]

I guess QGIS doesn't use the OpenFileGDB driver, but the FileGDB one, since I can reproduce with it :

ogrinfo qgis_bugreport_14407.gdb -sql "SELECT DISTINCT lbtyp FROM test_2p5D_qgis_support_03 ORDER BY lbtyp ASC"  -al -q -dialect SQL

(note the lack of -ro so that OGR tries to open in update mode, which is only supported by the FileGDB driver)

If you remove -dialect SQL, you will get the expected result.

The issue is that the FileGDB SDK has a buggy SQL implementation. Normally if you run ExecuteSQL() on a FileGDB datasource, the driver will *not* use the FileGDB SDK to evaluate it, *if* the dialect specified is NULL or "OGRSQL", but QGIS uses a "SQL" string that as far as I know is never explicitly handled by any OGR driver not the OGR core. I would just suggest using NULL instead of "SQL".

[ndawson]

Thanks - that change worked perfectly!