id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 1468,Bug with FID special field handling.,warmerdam,warmerdam,"{{{ Never mind this, I think I found the problem. There was a missing break statement in the following code: if ( iSpecialField < SPECIAL_FIELD_COUNT ) { switch ( SpecialFieldTypes[iSpecialField] ) { case SWQ_INTEGER: sField.Integer = poFeature->GetFieldAsInteger( op->field_index ); /***/ break; case SWQ_STRING: sField.String = (char*) poFeature->GetFieldAsString( op->field_index ); } } In the function OGRFeatureQueryEvaluator(). Adding the break after the SWQ_INTEGER case fixed query on FIDs. Traian -----Original Message----- From: Traian Stanev Sent: Wednesday, January 31, 2007 4:14 PM To: Frank Warmerdam (External) Subject: RE: [mapguide-internals] ogr postgis layer problems Hi Frank, I'm debugging the problem Paul is having. I think I found a problem in OGR when a filter of the form ""FID = 365"" is used. Around line 431 of OgrFeatureQuery.cpp, there is the following line: poIndex = poLayer->GetIndex()->GetFieldIndex( psExpr->field_index ); When the query is on FID, this returns NULL, resulting in the query returning no features. The field index used for FID seems to be a special index that's one bigger than the highes attribute field index of the layer. Any ideas about what I could do (in terms of calls to OGR) to avoid having to add special filter handling on the side of the FDO provider? I'm using GDAL 1.4.0. Traian }}}",defect,closed,normal,,OGR_SF,1.4.0,normal,fixed,,