Hi Survey123 community,
Has anyone else experienced this error since upgrading to 10.9.1?
We are using Survey 123 with Feature Services in Portal, against an enterprise geodatabase (not hosted). Our users are encountering an intermittent error when refreshing the inbox, that survey 123 is unable to retrieve related records. The feature service is working correctly, and we can query the relationship for the desired objectid's fine using the rest API.
When looking at the Survey123 logs it seems to be mixing up the relationship id's and querying the wrong relationship - because the query contains attributes that don't exist in the other relationship, the query fails with error 400.
Republishing the Survey123 form with the most recent Survey123 Connect seems to resolve the issue.
The Survey123 field app log shows;
<10>1 2022-02-15T13:13:18Z L999 ArcGISSurvey123 18372 - [AppStudio@11205 category="PortalRequest" function="onFailed" filename="PortalRequest.qml" line="116"] PortalRequest: PortalRequest failed url: https://myportal.org/server/rest/services/myservice/FeatureServer/1/queryRelatedRecords error: {
"code": 400,
"details": [],
"extendedCode": -2147467259,
"message": "Unable to complete operation."
and when we look at the query being constructed, it is building a query to the wrong relationship vs the feature service. That relationshipId is for another layer, that doesn't contain the same attributes. If I submit the same query against the feature service, for the wrong relationshipId I get the same error as Survey123.
<15>1 2022-02-15T13:13:18Z L489 ArcGISSurvey123 18372 - [AppStudio@11205 category="SurveyFolderPageInbox" function="addRelatedQueries" filename="SurveyFolderPageInbox.qml" line="711"] SurveyFolderPageInbox: relatedQueries: 3
<15>1 2022-02-15T13:13:18Z L489 ArcGISSurvey123 18372 - [AppStudio@11205 category="PortalRequest" function="next" filename="SurveyFolderPageInbox.qml" line="456"] PortalRequest: related query body: {
"objectIds": "5602,5603,5604,5605",
"relationshipId": 3,
"outFields": "objectid,globalid,last_edited_date,last_edited_user,created_date,created_user,activity_task_id,activity_id_points,task_point_label,parentrowid",
"outSR": 4326,
"returnGeometry": true,
"returnZ": true,
"returnM": false ...
Looking at the feature service page, the attributes in bold belong to a different relationship (in this case it's relationshipId 4). The relationships section of the feature layer;
"relationships": [
{
"id": 2,
"name": "activity_polylines",
"relatedTableId": 3,
"cardinality": "esriRelCardinalityOneToMany",
"role": "esriRelRoleOrigin",
"keyField": "uniquerowid",
"composite": true
},
{
"id": 3,
"name": "activity_polygons",
"relatedTableId": 4,
"cardinality": "esriRelCardinalityOneToMany",
"role": "esriRelRoleOrigin",
"keyField": "uniquerowid",
"composite": true
},
{
"id": 4,
"name": "activity_points",
"relatedTableId": 2,
"cardinality": "esriRelCardinalityOneToMany",
"role": "esriRelRoleOrigin",
"keyField": "uniquerowid",
"composite": true
},
{
"id": 0,
"name": "tasks",
"relatedTableId": 0,
"cardinality": "esriRelCardinalityOneToMany",
"role": "esriRelRoleDestination",
"keyField": "parentrowid",
"composite": true
}
Appreciate any tips on how to avoid this happening, as it isn't ideal to republish and re-download the survey when it occurs. We are publishing using connect version 3.13.251, and field app 3.13.246. The surveys were originally published some time ago with an older version of connect, and it seems republishing them with the latest version (following the portal upgrade) corrects the issue.
Thanks,
Andrew
