Opened 13 years ago

Last modified 13 years ago

#1468 closed defect (fixed)

Bug with FID special field handling.

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: OGR_SF Version: 1.4.0
Severity: normal Keywords:
Cc:

Description

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

Change History (1)

comment:1 Changed 13 years ago by warmerdam

Fixed bug in trunk and added test in autotest/ogr/ogr_basic_test.py for
fid (special field) queries - ogr_basic_5. 

Migrated fix and test into 1.4 branch as well.


Note: See TracTickets for help on using tickets.