Arithmetic Overflow send error and Converting XLSForm error

[AdamDaily]

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.

[RoryMcPherson__Stantec_]

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!

[Anonymous User]

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.

[AdamDaily]

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.

[AdamDaily]

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. 

[JamesTedrick · Accepted solution]

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

[AdamDaily]

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?

[JamesTedrick]

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.

[AdamDaily]

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!

[StephaneMoisy]

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,