I have an integer field in a survey that is used to store an 8-digit 'ID' field - e.g. 12345678. However if the user collects some values including the ID, closes the survey without sending, then re-opens it to edit/complete the survey, commas are added to the ID, the value is truncated, and the value shows as invalid - i.e. the ID above would be now show as 12,345,67 and would be in red text. (see attached).
I understand that this is because of the 9-character integer field limitation, but as far as I can tell this is new behaviour (or the survey team have changed their workflow...). Is there a way to stop this happening? We have already collected >1000 surveys using this form so I want to avoid changing the ID field to text if possible.
This issue is occurring as from 3.1 onwards in the field app we now honour and apply locale formatting correctly based on the system locale of the device or set in the survey, previously a bug was preventing this occurring properly, especially for those that use different locale formatting for numbers. So the use of comma thousand separators and decimal places or decimal comma are being applied after values are entered.
In the case of integer and decimal fields, a field length should never be set on these field types, this is actually a database limitation as it isn't applicable to integer/decimal fields, the field length setting should only be applied to string/text fields from a database perspective. Whilst in the past this may have worked in the field app, it will now cause the data to be truncated if more than 3 numbers which is the correct behaviour once the commas are added to the thousand separators.
The correct way to limit a integer or decimal field is to use an input mask, for example if you use 9999 the integer field will be limited to 4 numbers on input, and the locale formatting will be ignored and not applied when input mask is used.
Hope this helps,
I'm having a similar issue since downloading Survey123 version 3.2.265. My surveys (that were working fine) now return an 'Invalid integer value' error that prevents completed surveys from being submitted. The application is reformatting my integer fields to include commas that previously did not exist.
Is this due to the same issue mentioned above? I am not setting any field length or field type parameters. I do use pulldata function on some integer fields and default values on others (again, all were working in previous versions). Is there a way to get rid of the commas?
Thanks for replying, but I still think there is a problem here along the lines described by Adam. I've set up a test survey with only an integer field - no masks/ constraints etc. When completing the survey you can type in an 8-digit int - e.g. 12345678 - and if you send immediately it is correctly stored in the feature service. However if you choose to Send Later, then re-open the survey to edit it (e.g. to add in more details at a different location) the integer field is in red and shows as 12,345,67 with the last value truncated and the commas meaning an 'Invalid Integer Warning' is generated.
Is there a way around this?
Update...so I've added a Mask and that does solve the problem - I don't really need to limit the field, but this gets round the problem of commas being added to a 'saved draft' in the app.
Adam - if you've not done this before you basically just need to add something like "99999999" to the "body::esri::inputMask" field in the survey design spreadsheet.
I tried that and while the masking seems to fix the invalid integer error, I'm now having other problems. From a field phone, we were able to submit 1 survey and thought the issue had been fixed. On the 2nd survey, the app crashes. Now it crashes every time we try to open Survey. I went back into Survey Connect to look at it, and now Survey Connect on my desktop crashes every time I try to open it.
Can you please capture a log of the behavior and upload it to this thread?
Choose the option to log message to a file.
To capture messages to a file, click the Logging switch to enable logging. When no AppStudio console is selected, the Log output location text box is automatically populated with the default log file location.
Did you change the schema or remove the field length setting or any other to changes at same time as changing input mask?
I would suggest with any changes such as these that you test them on a copy of the survey (not your production survey) to ensure there is no data loss or issues with your production survey that other users may be using.
Only change was to the input mask. Does the length matter if the field values vary? 123 vs 123456 - should the mask be maxed out to # of allowable place holders of an integer field in the database?
My best guess to the crashing would be integer fields using pulldata function from .csv files in the media folder. Survey Connect crashed multiple times, so I created a new survey from my existing excel file. It seemed to work initially. Then I copied my tables over to the media folder, and on refreshing survey connect, it began crashing again. These tables have not changed and have been working in my surveys & previous Survey123 versions for over a year.
I'm pulling log files from our field crews mobile phones and will send those over to the thread you posted above.