OracleSpatial SQL Error w/FUNCTION = NONE

[jimk]

I can't even get a map to draw in 5.6 (works fine in 5.4)

DATA "POINT FROM (SELECT POINT,FEATURE_ID FROM FEATURES WHERE 
      FEATURE_TYPE_ID = 97) USING UNIQUE FEATURE_ID NONE 

The error message is like so (against trunk):

msDrawMap(): Image handling error. Failed to draw layer named 'layer1'.
msOracleSpatialLayerWhichShapes(): OracleSpatial error. 
  Error: ORA-01036: illegal variable name/number  . 
  Query statement: SELECT FEATURE_ID,, POINT FROM (SELECT POINT,FEATURE_ID 
    FROM FEATURES WHERE FEATURE_TYPE_ID = 97)

Not sure where the extra commas come from in the "Query statement: ..." line. Any ideas?

[jimk]

It is odd is that the Query Statement has two commas back to back, but I don't think that is the core problem.

SELECT FEATURE_ID,, POINT FROM ...

The following works for me in r9552 which is my latest build.

DATA 'GEOM FROM (SELECT FID,GEOM,SYSTEM_TYPE,DISPOSITION_STATE from SECTION_V) 
      USING UNIQUE FID SRID 26915 FILTER'

This also works for me:

DATA 'GEOM FROM (SELECT GEOM,FID from SECTION_V) USING UNIQUE FID SRID 26915 FILTER'

However this fails with the illegal variable name/number error:

DATA 'GEOM FROM (SELECT GEOM,FID from SECTION_V) USING UNIQUE FID SRID 26915 NONE'

So... it seems related to having function = NONE.

I suspect this may be related to the change to use bind variables in the SQL instead of passing parameters directly in r9295.

[jimk]

Fix where msOracleSpatialWhichShapes tries to assign to bind variables that aren't there.

[jimk]

The problem was the new code that is using bind variables in msOracleSpatialLayerWhichShapes was failing in the case of FUNCTION=NONE because there were no variables to bind. I added a condition so it will not try to assign the bind variables when FUNCTION=NONE.

Steve tried the patch against 5.6 branch and it worked ok.

[jimk]

Looks like assefa also fixed this as part of r9668 in trunk.

[sdlime]

Fixed in 5.6 branch in r9684. -Steve

[sdlime]

5.6 works now. The main trunk segfaults on the same mapfile. I've not tried applying Jim's patch to trunk though. At worse I would have expected the same old error message I was seeing.

Steve

[aboudreault]

It may be related to this ticket: ​http://trac.osgeo.org/mapserver/ticket/3228
Have to check if we revert the change about duplicate field names in the sql query.