Error with calculation field since upgrade to 1.9

[PhilipWilson-GIS]

We have just upgraded to Survey123 v1.9 and re-published a survey. Using the latest version 1.9.24 app also on iPhone/iPad and Android. Previously we used a calculation to total the sum of 8 cost fields:

int(${roof_cost})+int(${exterior_cost})+int(${subfloor_cost})+int(${rooms_cost})+int(${doors_cost})+int(${windows_cost})+int(${services_cost})+int(${setting_cost})

This worked perfectly before and has done since version 1.0 of Survey123. Now the calculation does not work, it remains blank in the form when values are entered into the above fields, and if you type a custom value into the total cost field, save draft, close the survey and open again, the custom value does not get saved (which it used to also).

Any ideas?

[MitchellProctor · Accepted solution]

Hi Philip,

This is likely a result of the way Survey123 handles empty values in questions starting in 1.9. The handling is described in full here: Formulas—Survey123 for ArcGIS | ArcGIS But in short, your calculation won't produce a result until there are values present for all fields being used.

The easiest way to fix this would be to give each field a default value of 0.

[PhilipWilson-GIS]

Thanks Mitchell,

That did the trick. Have given all the fields a default value of 0 and working fine. Good to know for future and other Survery123 forms we use, as it wasn't a requirement previously many of them will have nulls where a value will be expected.

Phil.

[WengNg]

I have a similar issue with a calculate field which calculates the amount of days between two dates. I have it forced as an esriFieldTypeInteger type and the form returns a code 1000 error which complains about converting NaN to an integer field.

I had to modify my calculate field so that it returns a value of 0 when there are no user inputs to fix this. I thought this was a somewhat strange behaviour because I thought NaN is a valid input in an integer field.

[JamesTedrick]

Hi Weng,

I think what you're thinking of in terms of integers field input is null, which is a valid input value; NaN isn't.  There's a slight difference between NaN and null programmatically; while they represent the same concept, they are not equivalent.

[WengNg]

HI James,

In Formulas—Survey123 for ArcGIS | ArcGIS, the document specifies that empty values are handled like this :

• NaN (not a number) for integer and decimal questions. This is a special value that represents the absence of a valid value.
• '' (an empty string) for text questions. The default data type for select_one, select_mulitple, and hidden questions is also text. When these question types are empty they will contain an empty string.

If I follow this correctly, an integer question will default to NaN when it is empty. Wouldn't that break the form since an integer field cannot accept NaN values? I thought it would make more sense for it to default to a null value instead of a NaN.

[JamesTedrick]

Hi Weng,

Yes, you're right about the discrepancy in values in the client application and what the feature service endpoint can accept.  In response to your question and my response, I entered an issue into our development team to fix this behavior- we'll have it updated to submit null (but still use NaN in the app) in the next version.

[AndrewHargreaves2]

James Tedrick‌

Please can you offer some guidance on how I set up a relevant on an integer field? I've tried all of the below and get no success:

${ESRIGNSS_NUMSATS}=''

${ESRIGNSS_NUMSATS}=null

${ESRIGNSS_NUMSATS}=NaN

Thanks

[JamesTedrick]

Hi Andrew,

As per Formulas—Survey123 for ArcGIS | ArcGIS, the string-length() function will return 0 for all questions if the question is empty; it can be used for testing whether a question is empty or not (including non-text questions).