Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#6415 closed defect (invalid)

OpenFileGDB data source returns wrong values for SELECT DISTINCT queries

Reported by: ndawson Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords:


(original bug report here: )

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

I've attached a dataset which demonstrates this issue.

Change History (3)

comment:1 Changed 6 years ago by ndawson

Apologies - I cannot get the dataset small enough to attach here. It's available at

comment:2 Changed 6 years ago by Even Rouault

Resolution: invalid
Status: newclosed

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".

comment:3 Changed 6 years ago by ndawson

Thanks - that change worked perfectly!

Note: See TracTickets for help on using tickets.