query shapefile with underscore returns 0 results

[jbchurchill]

I am using mapserver with an MS4W installation on Windows XP My shapefile that I am querying has a field called "filename" and that field contains the filenames of several images that we have on our network. The filename typically has a lot of underscore characters and some hyphens and periods (dots) e.g. p033r032_07-05-1996_lt5.img

The problem I'm experiencing is that a query for this precise result returns 0 results even though that it is precisely what is in the shapefile dbf table. I discovered that it is the underscore that causes a problem and that if I take it out and replace it with a hyphen (or dash "-") everything works just fine.

+++++++++++++ MORE INFO ++++++++++++++++++++++++++ I described this problem to the Mapserver Users list and was asked by Steve Lime to file a bug report. My first post to the list was on 7/2/07 and I posted this follow up on 7/5/07 after doing some testing on my own.

I figured out the problem I was having. It has to do with having underscores "_" in the text field. If I replace my underscores with hyphens "-", my query works. This seems to be an odd character for Mapserver to weed out but that appears to be what is happening.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Hi All,

I'm having trouble executing an Attribute Query when I base the query (qitem) on the "filename" field in my shapefile. I can choose any other field and supply the appropriate qstring and everything works fine but when I use the filename field I get a "no matching records" found error.

The text in the long string in the address bar of the browser IS complete and DOES match the value in the shapefile. Perhaps the text values in the shapefile field are too long for MapServer or special characters like the "." or "-" are causing a problem ? Can anyone confirm or deny either of my theories about this or point to any other possibilities ?

The qstring is ... p016r032_09-09-1986_lt5_doc.img

The qitem is "filename" and it is a text field.

The entire query string in the address bar is ... ​http://localhost/cgi-bin/mapserv.exe?qlayer=landsat_4&myitem=landsat_4%2Cfilename&qstring=p016r032_09-09-1986_lt5_doc.img&map=C%3A%5Cms4w%5CApache%5Chtdocs%5Cimg_browser%5Cimg_browser.map&program=%2Fcgi-bin%2Fmapserv&mode=itemnquery&qitem=filename

The error is ... msQueryByAttributes(): Search returned no results. No matching record(s) found.

[unicoletti]

We have reworked some parts of the string parsing routines, could you confirm that the issue is still present in the latest 5.0 beta?

[sdlime]

The easiest way to get at this one would be with a copy of the data that is causing problems. Could that be shared?

Steve

[jbchurchill]

zip with shapefile, mapfile, and php query script

[jbchurchill]

I tested this as asked and the 5.0 beta appears to fix the problem. I'm not sure why but running my map application with the beta is returning a new error ... loadWeb(): Unknown identifier. Parsing error near (C):(line 1) so I may have to return to my old installation (or maybe I just have to restart or something).

I'm attaching one of the shapefiles that demonstrates the problem "landsat_4.shp". You may not want or need all the other stuff but I'll also include my attribute query scripts (3 php files that work together), and my map file ("img_browser.map"). I'll put all this in a zip file ("underscore.zip").

I used ms4w and the img_browser folder housed all these files except the shapefile which was in the data folder ... C:\ms4w\Apache\htdocs\img_browser\data

If you need me to set the action to resolve, I can but I'm assuming you have the permissions to do that yourselves.

[sdlime]

The parsing URL configuration has definitely changed (hopefully for the better) in 5.0. This was in an attempt to unify URL/FILE/STRING configuration parsing. Are you doing URL configuration? If so, please post a URL that is blowing up.

Steve

[sdlime]

The core bug is fixed though... so marking as such.

Steve