First I want to clarify a couple of things I wrote incorrectly before. I said I was now able to get records back from the query, but they had no data. That lacked a step. The records from the query on the layer using getResult do have good data now, but when I try to getShape using that data, the result is not good. Also, I said the bound values were zero for the bad shapes, but they are minus one.
Eric, I don't think the php_mapscript library is working the same as the mapscript library (see response to Kristjan). Your suggestion to use a lookup array will provide a work around for php, now that one can get the index value back from the layer->getResult after queryByPoint with php_mapscript. But it will also be necessary to get data from the database instead of the shape. I know that this would likely be wanted anyway, but it should not be required to get the data that was just put into the shape. It will be necessary to do a check to see if a layer is 'dynamic'* to do a database query rather than just going into the shape like all the other layers. * yes, all the layers are dynamic, i mean that the layer was created using mapscript as opposed to being loaded from a mapfile. Kristjan, are you using PHP or perl? I have not been able to use the id from the database table for shape index values. Are you autoindexing your table? I find that the shape index values need to have values from zero to the number of points added to the layer, but that they do not necessarily have to be added in order. I find that any points added that have an index value set for the point shape that is equal to or greater than the number of points added to my new layer generate the following error in php_mapscript when I queryByPoint that point shape: Fatal error: [MapServer Error]: msINLINELayerGetShape(): No inline feature with this index. (This is the same error from earlier versions that did not allow the index value to be set in php_mapscript. All getResult shapeindex values were -1 at that time.) I try not to auto index my tables, so I have not checked this but it would seem if one were auto-indexing and if auto indexing starts at 1, that would mean that the point with the highest index would generate this error even though all the others worked. For every record deleted from the table, the situation would get progressively worse for entries that were subsequently added because their index value would be too high. If one only clicked on points on the map that had index values less than the number of points added, no error would be generated. IF THIS IS WRONG, HOPEFULLY SOMEONE WILL LET EVERYONE KNOW. Thanks for the response's. I think I will recode the page in perl and see what happens.
