Issue with query parameter not working in search() appearance in Survey123 Connect

[MiltonSolano]

Hi all,

I’m currently developing a survey in Survey123 Connect, and I’ve encountered an issue when trying to use query parameters in the REST URL within the search() appearance for a select_one question.

According to the documentation, it's possible to filter results from a feature layer by adding a query string directly to the REST URL. However, any filter I apply using the where clause is completely ignored. For example:

search("available?url=https://services2.arcgis.com/xyzxy/arcgis/rest/services/BoatSchedules/FeatureServer/0/query?where=Re... > CURRENT_TIMESTAMP", "matches", "ScheduleQuery", ${ScheduleQuery}, "Trip_Type", "Public")

This URL returns all records, not just the ones where Reservation_Date > CURRENT_TIMESTAMP.

Curiously, when I add an orderByFields parameter:

search("available?url=https://services2.arcgis.com/xyzxy/arcgis/rest/services/BoatSchedules/FeatureServer/0/query?where=Re... > CURRENT_TIMESTAMP&orderByFields=Reservation_Date", "matches", "ScheduleQuery", ${ScheduleQuery}, "Trip_Type", "Public")

…the list does return ordered by date, so I know the query string is at least being passed. But the where clause is still not being honored—all records are returned regardless of the date filter.

I’ve confirmed that the query works as expected when tested directly in the REST endpoint, so the issue seems to be specific to how the search() appearance handles the URL in Survey123 Connect.

I checked the request send by the search() appearance on the browser and noticed two QUERY tags appended to the request, both with the query parameters. See attached screenshot. I guess if this is expected behavior.

Also worth noting: the official documentation for search() at
https://doc.arcgis.com/en/survey123/desktop/create-surveys/xlsformsappearance.htm#ESRI_SECTION1_46A7...
has incomplete or incorrect examples for how to properly structure REST query parameters. This may be contributing to the confusion.

Has anyone experienced similar issues or found a workaround? Is this a known limitation or possibly a bug?

Thanks in advance!

MJ

[Neal_t_k]

might be some syntax errors in there

try: ...FeatureServer/0/&where=

instead of ...FeatureServer/0/query?where=

[MiltonSolano]

@Neal_t_k,

Thanks for the suggestion, but is not related to how to build the REST query. When the REST url is bad constructed, the search() ignores the query. See the next screenshot where I wrote the query url using your suggestion:

Just one "where" clause from the search() function. But if you build the query url properly, you get this:

Two "where" clauses: one from the query url and another one from the search() function. I don't know if this is expected behavior or a bug. The thing is the first "where" clause is ignored and not honored.

MJ

[Neal_t_k · Accepted solution]

I am just going by this:

It seems querying directly from REST and in Survery123 have different syntax,  I just tried a where clause with 2 arguments with sample data and it worked in survey123 Connect. 

[MiltonSolano · Accepted solution]

@Neal_t_k,

Thanks for not giving up and suggest a new idea. It worked... with caveats. It worked on the web but not on the app itself. In the Survey123 app, the list shows empty, no records. On the webapp, the list is correctly filtered. Because my project will use the webapp, I can move on like this but surely someone will need this fixed for the app.

And for those looking for the straight answer, I changed my REST URL request from:

/FeatureServer/0/query?where=", ${now_epoch},"&orderByFields=Reservation_Date"

to

/FeatureServer/0?where=", ${now_epoch},"&orderByFields=Reservation_Date"

Where "now_epoch" is calculated field with the datetime field and a timestamp.

MJ

[Neal_t_k · Accepted solution]

Curious, did you try making that "?" an "&".  I see I misread that from the post I went off of, but it did work for me in connect with the "&".

[MiltonSolano]

@Neal_t_k 

Aaaaaarrgggg... I really hate when I think something is production-ready, and then—boom—turns out it’s not. Someone changed something that made it look like it was working… but it wasn’t.

Here’s what happened.

I initially changed the query URL from this:
/FeatureServer/0/query?where=", ${now_epoch2},"&orderByFields=Reservation_Date"
to this:
/FeatureServer/0?where=", ${now_epoch2},"&orderByFields=Reservation_Date"

It looked like it was working because someone had updated the schedule and results seemed correct. BUT… after inspecting the request being sent, I realized two separate queries were being executed. (See screenshot below.)

Following your advice, I replaced the first ? with an &, like this:
/FeatureServer/0&where=", ${now_epoch2},"&orderByFields=Reservation_Date"

This time, the request sent only ONE query, with all conditions inside—finally the correct behavior. Still, I wasn't getting the expected filtered results. So I took it one step further and replaced the use of a calculated field with the SQL keyword directly. The final working URL became:
/FeatureServer/0?where=Reservation_Date > CURRENT_TIMESTAMP&orderByFields=Reservation_Date
(See screenshot for reference below.)

Now it’s correctly filtering the records on the WEB; on the app is returning the whole list with no filters. Thanks for letting me play forensic detective on this one!

MJ