Find Operation Does Not Work If SHAPE.LEN Is In Search Field List

[RyanCoodey]

If SHAPE.LEN is in the list of Search Fields, I always get "No results found", regardless of what other field I might be searching.  If I remove SHAPE.LEN then the Find works fine.  Is this a bug? Or is this supposed to work this way?

I hav not tested SHAPE.AREA yet, it might do the same...

Thanks a lot!

[EricPaitz]

Is your Map Service being published from an MXD or an MSD?

[RyanCoodey]

Its an MSD... thanks!

[EricPaitz]

OK I have seen just this week that there might be an issue with the REST Find Operation and a service published from an MSD vs. and MXD. Specifically we are using SQL Server 2008 and ArcSDE 9.3.1. We noticed a possible issue with text fields that hold numeric values like 1234. I have not tried to query the area or length fields.

For now try and publish your Map Service from the MXD and see if it works any better. If it does then for now I think you have to use the MXD. We wanted to use the MSD because of transparency issues, what do you need the MSD? Are you using SDE? If so what version and specifically which RDBMS are you using (SDE, Oracle, etc...)?

[RyanCoodey]

Thanks a lot for the info Eric!

Our find tool has an option to search "all" data fields, so for now I have just tweaked that tool to skip over SHAPE.x fields.  This is a fine solution for now.  I would prefer to leave the services as MSD, just for the slight performance gain, but don't necessarily have too.

We are running SDE 9.3 on Oracle 10g

Thanks again for the help!

[Drew]

OK I have seen just this week that there might be an issue with the REST Find Operation and a service published from an MSD vs. and MXD. Specifically we are using SQL Server 2008 and ArcSDE 9.3.1. We noticed a possible issue with text fields that hold numeric values like 1234. I have not tried to query the area or length fields.

For now try and publish your Map Service from the MXD and see if it works any better. If it does then for now I think you have to use the MXD. We wanted to use the MSD because of transparency issues, what do you need the MSD? Are you using SDE? If so what version and specifically which RDBMS are you using (SDE, Oracle, etc...)?

This seems to be the problem for us also.. Our MSD base services do not 'FIND' values such as 123456.  Currently  we do not have the latest SP installed, has there been a fix for this yet? I can not find any release notes about it in the latest SP (10.0 SP2) release.

Thanks.

Drew

[RaviNarayanan]

Drew,

FIND will find values such as "123456" as long as this value is stored in a string field. is that the use case here or is that value stored in a numeric field?

Ravi

[Drew]

Drew,

FIND will find values such as "123456" as long as this value is stored in a string field. is that the use case here or is that value stored in a numeric field?

Ravi

Ravi

We do have the number in a string field. Our solution is to publish the MXD instead of the MSD. We found that the FIND opertation does not function as expected when using an MSD.

Drew

[SrinivasVinnakota]

Andrew,
Find works fine on numbers stored as strings in an optimized mapservices (using msd).  http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/BloomfieldHillsMichigan/Parcels/MapServer...

If you would look at the layer information you should notice that [parcelid] is a string field.

[Drew]

Thanks for the samples guys.
Here is a service you can see my problem with.

You can test a working FIND operation on an ARN (Assessment Roll Number) here
http://maps.simcoe.ca/ArcGIS/rest/services/Dynamic_UnSecured/DUA_SearchLayers/MapServer/find?searchT...

It is my understanding that if no searchFields are specified all fields are searched. So by removing the ARN field from the request it should produce the same results, but my testing shows it does not. You can test here.
http://maps.simcoe.ca/ArcGIS/rest/services/Dynamic_UnSecured/DUA_SearchLayers/MapServer/find?searchT...

When using an MXD both work, but in an MSD only the one with the field specified works.
Thanks for taking the time to assist.

Andrew