Esearch - Error 1009

[Scott_Russell]

Hello,

I posted a question similar to this in the Flex API forum yesterday.  I am attempting to perform a SQL query for a TEXT field that is in our Valves feature class.  The field is an ID number field but also contains letters. I'd like the user to have the ability to type in a valve number and successfully select it.  Here is what I have so far:

<configuration>
    <layers>
        <layer>
            <definitionexpression/>
            <enableexport>true</enableexport>
            <name>Valves</name>
            <url>http://valhalla:6080/arcgis/rest/services/WebMap/MapServer/9</url>
            <expressions>
                <expression alias="Valve ID Search" textsearchlabel="Search Valve ID:">
                    <values>
                        <value prompt="Example:100">FACILITYID = '[value]'</value>
                    </values>
                </expression>
            </expressions>
            <graphicalsearchlabel>Use one of the graphical search tools to select Valves</graphicalsearchlabel>
            <spatialsearchlayer>true</spatialsearchlayer>
            <titlefield>FACILITYID</titlefield>
            <fields all="true"/>
            <links/>
            <zoomscale usegeometry="true" zoompercent="2"/>
        </layer>

Keep in mind that although this is a field used for IDs and most values are numeric, the field is a TEXT field which contains letters in some cases.

When I attempt to perform the above action I receive Error #1009.  What am I doing wrong?  I have confirmed that FACILITYID is the field alias within the table.  I determined the URL by clicking on the Valves layer link in the REST services URL in ArcGIS Server.

Thanks,
Scott

EDIT: I'd like to point out that FACILITID = '[value]' yields results in the default Search widget in the Flex Viewer.

[RhettZufelt]

Well, not sure what else I can do to help as I avoid SDE like the plague and am only running server 10.0 so can't really test much.

If the new column doesn't work, if it were me, I'd export the data to a FGDB feature class, make a new service from that, then try to search again.  Would also try to search other fields in the same service.

Sometimes it is easier to try to find something that does work, then try to figure it from there (or just move on ) 🙂

R_

[RobertScheitlin__GISP]

Scott,

   Here you go replace all your xml for the eSearch Widget with what you copy from the attachment and see if that fixes it.

[CoryHines]

My apologies guys.

I just noticed that I had the same issue going on.  I did discover what the problem was.  I had a date field being returned, but didn't add the data format tag in the xml.  I don't know if this is the same issue you are having Scott since you are returning all fields without specifying them individually.

<field name="DATE_" alias="Date Recorded" dateformat="MM/DD/YYYY"/>

Again, my apologies for posting in the incorrect post.

Thanks guys.

[RobertScheitlin__GISP]

Cory,

   No worries. I just wanted be sure not to get off helping with your issue when Scott's issue had not be resolved. I did find the dateformat issue a little after you had posted your issue so you posting did help. I will have the dateformat bug trapped in the next version. BTW I take care of this in the code but the new spark date format is "MM/dd/yyyy". This is actually the reason for the bug in the 3.0.7 as I was attempting to fix the dateformat and there were some that were not specifying it like you and all those people that are using all fields. But in the next version this will not be an issue. As I mentioned earlier you my want to make this correction to your xml so that the user will have an example of a subdivision to use:

            <expressions>
                <expression alias="Subdivision Name" textsearchlabel="Search Subdivision Name">
                    <values>
                        <value prompt="Example: BOYSON ROAD 1ST">SUBDIVISIONNAME LIKE '[value]%'</value>
                    </values>
                </expression>
            </expressions>

[CoryHines]

Will do Robert.  I need to add quite a few "helper" items before I push this out.

As for Scott's issue.  Maybe attempt to specify just one field for the return results?

Good luck.

[RobertScheitlin__GISP]

Cory,

   I gave him a complete eSearchWidget.xml configured for his layer and he should be good to go with that.

[Scott_Russell]

Scott, 

Here you go replace all your xml for the eSearch Widget with what you copy from the attachment and see if that fixes it.

Robert,

I copy/pasted the contents of that XML into the eSearch widget. When I enter a value and click search there is no following action. There is no error, it just seems as if the function does not respond.

Scott


EDIT: ROBERT!! IT WORKED!!! I replaced the existing REST URL with our own, and everything is functional!! I'm stoked! Thank you so much for putting so much time into this, it must have taken you a while to type out all of these fields. Thank you VERY much!!

What do you think was wrong?

[RobertScheitlin__GISP · Accepted solution]

Scott,

   As mentioned in the couple of post above there is a bug when not specifying a dateformat in the eSearchWidget.xml and because you choose to use fields all = "true" you ended up encountering this error. I will have this fixed in version 3.0.8 along with some other great little additions. So make sure you stay current with the releases of this widget.

Don't forget to click the Mark as answer check on this post and to click the top arrow (promote).
Follow the steps as shown in the below graphic:

[RhettZufelt]

Robert,  I wondered if the all="true" had something to do with it, so I tested as much as I could with that (with services that have and do not have a date field).

Could not make it give me that error using FGDB FC with server 10.0 and using the uncompiled version.

Not sure if this only happens in app builder or not as I do not use app builder myself.

In case this might help you "fix" it,

R_

[Gyeong_MinRoh]

Robert,

I also had the same error #1009 and already solved it as you explained above.
Thank you.