topic Re: Arithmetic Overflow send error and Converting XLSForm error in ArcGIS Survey123 Questions

Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Wed, 11 Jul 2018 18:48:22 GMT

I published a survey that seemed to be working fine. Field crew were submitting completed surveys and using it. Then on several surveys, the app stopped working and they started getting the below error.

When I went back into Survey Connect to try and figure out the error, I started getting a new and different error in Connect:

I cant find much on either error, and now field crew cant submit surveys, and I cant publish a new one. Any help anyone can offer as to what these errors are referencing would be much appreciated.

I have checked the .csv file referenced in the error, the field types compared to my hosted feature service, my pulldata functions in the survey, my choices list, submission URL, and the instance_name in settings (although I don't know why that even matters plus I have inbox disabled). Don't know what else to even look at.

Re: Arithmetic Overflow send error and Converting XLSForm error

RoryMcPherson__Stantec_ — Thu, 12 Jul 2018 20:42:54 GMT

I'm having the same issue on a single survey entry. Also not sure what's causing the issue. Will wait and hope for a response!

Re: Arithmetic Overflow send error and Converting XLSForm error

Anonymous User — Wed, 18 Jul 2018 06:15:21 GMT

Hi Adam,

For the first issue you encountered, can you provide a copy of your xslx form to check the calculations that may be causing this issue? Is this a new issue since upgrading to 3.0 version of the app? Did it work fine in 2.8?

It sounds as those the second issue may be related to the latest update to Pyxform which was upgraded with our 3.0 release. The duplicate URI error you provided in Connect, this is likely due to there being duplicate choice list names in the xlsx file or a choice list name that has the exact same name as an external csv file in media folder being used by a pulldata() calculation. Are you able to check to see if that is the case? I have seen this before, and either renaming the choice list or the external csv file resolved the issue.

Regards,

Phil.

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Wed, 18 Jul 2018 18:04:32 GMT

Thanks for the reply Philip,

It was a new issue I have not encountered before. Unfortunately I no longer have that xlsx as I rebuilt the survey trying to determine the problem. I believe it was an issue with trying to use multiple fields to capture 1 attribute. Fields set-up with opposite relevant filters, and using either pulldata or cascading selects. I ended up removing the cascading selects to make this work, and consolidated those to 1 select-one list.

What you mentioned sounds like the issue I had, "duplicate choice list names", and the error occurring following a version update. Although I am on Version 2.8.4, so if 3.0 is out I will need to update again. Thank you for the response, I will be aware of this going forward.

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Thu, 26 Jul 2018 15:40:59 GMT

Philip,

I thought I had the issue fixed, but even after rebuilding the survey and testing (seemed fine during testing in Connect), after publishing our field crew is getting the same error message. I'm not sure what else to check at this point.

Re: Arithmetic Overflow send error and Converting XLSForm error

JamesTedrick — Wed, 01 Aug 2018 22:28:10 GMT

Hi Adam,

It looks like your classification values are very large integers - those should be stored in a text field (your form currently has that set as an integer field via the bind:Esri:fieldType column).

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Thu, 02 Aug 2018 17:15:43 GMT

James,

I was experimenting with that field as I noticed my pulldata calcs stopped working correctly depending on the field value type of "classification". I have multiple other surveys constructed similarly, all set up with that "classification" field set to integer (not thru bind:esri). I was using text with bind:esri Integer to try and fix my pulldata functions.

This seems to be another/unrelated issue. My underlying feature service "classification" field is set to integer. I have 6 other surveys writing to that same service and all seem to be working ok when submitting completed surveys. It is just this 1 survey, and only certain feature types within it "FM200" being the main one, (out of 7 surveys and probably 50 or so feature types) that produce this error and will not send. I have tried using text and integer in the field "classification", but that seems to be unrelated to whatever is causing this issue.

Is it possible to change a field type in the underlying feature service as well as make that change to that field in my surveys writing to it, without taking down the entire service and republishing all of the surveys?

Re: Arithmetic Overflow send error and Converting XLSForm error

JamesTedrick — Thu, 02 Aug 2018 17:24:31 GMT

Hi Adam,

Changing the field type of a field would require a republishing. It is safer to add a new field and point the question to the new field instead; as part of the creation, you can calculate the old field's data into the new field.

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Fri, 03 Aug 2018 15:18:23 GMT

James,

I went back and took a look at my pull-data tables. The classification codes I had for the features that were not working properly were longer integers then all of the others. Thank you for looking at this and leading me to the issue, that absolutely was what was causing that error. Fixing that line in my csv file fixed everything in my survey. Thank you!

Re: Arithmetic Overflow send error and Converting XLSForm error

StephaneMoisy — Wed, 29 May 2019 08:46:26 GMT

Hi,

I published a survey that seemed to be working fine. Field crew were submitting completed surveys and using it. Then at the time of submitting the survey I encounter the problem: <<Arithmetic overflow error converting expression to data type int. he statement has been terminated >>. (see attachment)

After hours of browsing the forums, especially this one, no solution already proposed unfortunately corresponds to my situation. Yes, I was able to detect the source of the ERROR problem I unfortunately do not have the solution. Indeed, in my survey, I defined some text fields as integer via the column bind:Esri:fieldType (EsriFieldString : A series of alphanumeric symbols) and 255 as bind:esri:fieldLength). Therefore, it is impossible to submit the survey despite the fact that I have modified some results to match the data types.

Please any help that anyone can offer would be greatly appreciated.

I would like to point out that the investigation has not yet been submitted and it is still in the mailbox of the device.

Thanks,

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Wed, 29 May 2019 17:42:27 GMT

I believe integer fields have a 9 character length limit to them. You also may need to try masking your integer field values. My integer fields stopped working upon downloading a newer release of Survey. I had to republish ones that previously worked using body::esri:inputMask for my integer values.

Re: Arithmetic Overflow send error and Converting XLSForm error

JamesTedrick — Wed, 29 May 2019 19:31:23 GMT

Hi Stephane,

Can you provide examples of the data that is being submitted and causing the error? If you are using an Input Mask, what is the mask format (does it include non-numeric elements)?

Re: Arithmetic Overflow send error and Converting XLSForm error

StephaneMoisy — Fri, 31 May 2019 10:06:58 GMT

Hello Adam,

I didn't use an input mask, but rather custom columns bind::esri:fieldType and bind::esri:fieldLength. And the type of data in the line that returns the error msg is a text. It is possible to make changes to my spreadsheet and republish but I would lose my surveys.

Re: Arithmetic Overflow send error and Converting XLSForm error

StephaneMoisy — Fri, 31 May 2019 10:14:50 GMT

Hi James,

I don't use an input mask, but rather custom columns bind::esri:fieldType and bind::esri:fieldLength. And the type of data in the line that returns the error msg is a text. You can see the screen shot please.

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Fri, 31 May 2019 17:41:28 GMT

Stephane,

If you don't change the field names, you can publish a new survey that writes to your existing surveys database, without deleting or republishing your existing survey. You can make a copy, make your changes, and publish that copy using a submission_url within the settings page.

Re: Arithmetic Overflow send error and Converting XLSForm error

JanelleLeza — Fri, 31 May 2019 23:39:32 GMT

Hi James,

I am experiencing a similar issue; however, I did include an input mask.

Previously no error message but an issue with the integer format

In my case, my surveys had previously submitted with no error message. There was, however, a discrepancy with the manner in which the integer (masked as an US phone number) appeared in the Survey123 Connect for ArcGIS vs. the submitted survey in the Survey123 web application; in Connect, it appeared to be working just fine (123-123-1234), but in viewing the submitted survey in the Survey123 web application it appeared as 1,231,231,234.

Survey123 Connect

Survey123 web application

Now receiving same error message as Stephane

Currently, I am receiving the same error message as Stephane.

When I check the Survey123 web application, the surveys are, indeed, not submitting. I am, however, receiving the emails that I had set up to send via MS Flow for when this survey is submitted.

Thank you so much for any assistance or advice you may be able to provide!

Re: Arithmetic Overflow send error and Converting XLSForm error

StephaneMoisy — Sun, 02 Jun 2019 20:11:19 GMT

Thank Adam,
But can an you be more explicit about the solution please propose?

Because my difficulty is to be able to find a solution to recover surveys without losing the results available in the collection device.

Re: Arithmetic Overflow send error and Converting XLSForm error

AdamDaily — Mon, 03 Jun 2019 14:50:40 GMT

Go to your AGOL portal/online account and open up the Services URL of your hosted feature layer. Within this page, look at the URL bar directly above, and the line directly below, where it says ArcGIS REST Services Directory. Copy the URL from https:// up through /FeatureServer and paste this into the Submission_url line in your excel survey settings worksheet through Connect. For form_id, use the name of your (FeatureServer)> "Name"

Again, this is to write a new survey to your existing db. It wont necessarily solve the issue with arithmetic overflow error, but it can give you a live collection service to test with.

Re: Arithmetic Overflow send error and Converting XLSForm error

JamesTedrick — Mon, 03 Jun 2019 20:02:20 GMT

Hi Janelle,

Phone numbers should be stored as text, not integers. If you ask for them as integers, the form will try to process '123-123-1234' and does not know how to handle the '-'.

Re: Arithmetic Overflow send error and Converting XLSForm error

StephaneMoisy — Tue, 04 Jun 2019 07:00:04 GMT

Thank you all,

Following the different explanations, we used the URL service https://doc.arcgis.com/fr/survey123/desktop/create-surveys/survey123withexistingfeatureservices.htm.

This allowed us to update the existing survey and send the statements. Also, we had to choose "null" in the bind:esri:fieldType for some information that could be easily found (date, time, name of the observer...).

Yours sincerely!