Arithmetic Overflow send error and Converting XLSForm error

2994
22
Jump to solution
07-11-2018 11:48 AM
AdamDaily
Occasional Contributor II

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.

22 Replies
AdamDaily
Occasional Contributor II

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. 

0 Kudos
StephaneMoisy
New Contributor III

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.

0 Kudos
AdamDaily
Occasional Contributor II

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.

0 Kudos
StephaneMoisy
New Contributor III

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.

0 Kudos
AdamDaily
Occasional Contributor II

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.

StephaneMoisy
New Contributor III

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!

0 Kudos
JamesTedrick
Esri Esteemed Contributor

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)?

0 Kudos
StephaneMoisy
New Contributor III

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.

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Stephane,

Is this the entire form?  The error you received should only be generated when there is an integer question/field.  Also, did Survey123 Connect publish the feature layer, or did it exist before?  

0 Kudos
StephaneMoisy
New Contributor III

Hi James,

It was a few fields that were problematic when there was bind::esri:fieldType: esriFieldTypeString. So I replaced by null then republished through the url and it works.

Thank you!

0 Kudos