Survey123 Choice values get stripped of leading zeros

[TonyDaSilva1]

Hi,
I think there is a bug with string based values for select_one text fields where if the text looks like a integer but is preceded by zeros (000123) it gets stripped and ends up in the feature class like (123). 

Please fix this.

Thanks,

[KristofferWaageBeck]

HI Tony..

Assuming you use Survey Connect App

For what it's worth.. I my memory serves me correct:

On the Survey pane select your field.. Go all the way out to column S Called bind::esri:FieldType in the drop down select the the data type esriFieldTypeString.

I am not 100% sure that does the trick. But worth while trying 🙂

Kind regards

Kristoffer W Beck (former Senior Supporter for Esri distributor in Denmark)

[E_-_MarieCook__GISS_]

We are experiencing the same issue after the Feb 25 field app update, despite the field type being set to string. Any workarounds, @JamesTedrick? @IsmaelChivite? Thanks, guys!!

 

[GianniCampanile2]

We have the same problem too: leading 0 are stripped both from choices lists or from pulldata values. Version 3.11 is fine, version 3.12.244 and 277 have this bug. Even if you define text values in Excel, of using the ' sign to force text it does not work  (and in any case it could not work for pulldata).

Field is defintely defined as EsriTypeString.

Gianni

[JamesTedrick]

Hi @TonyDaSilva1 @E_-_MarieCook__GISS_ @GianniCampanile2 ,

Apologies for the delay in responding to this.

With 3.12, there was a change in how lists are managed internally.  One of the changes addressed a set of BUGs that had been registered regarding the processing of choices with numeric values (for instance, numeric values being used in cascading selects); to address this, choice values are now being converted into a numeric type if possible.  While we had this change in the Early Adopter Community for a number of months without issue, we are receiving reports in situations like you describe, where the values are number-like strings that have leading zeros.  There are a couple of workarounds that can be used to ensure proper processing:

• If the number has at most 1 leading zero and a known length, it generally is feasible to have a subsequent calculation that prepends the zero by comparing the string-length value; for example, if an example value is 05678 (five digits with a leading zero), the function if(string-length(${q}) < 5, concat(‘0’,${q}),${q}) can be used to add the zero back to the string
• The choices could be altered to be processed as a string by prepending a character (such as ‘_’) and then a subsequent calculation removes the character: substr(${q},1)

Both of these workarounds uses a second, calculate question to process the value in the form; this can be used in combination with setting the select_one/select_multiple's bind:esri:fieldType to null so that the intermediate value is not stored.

 Given the feedback, we are investigating ways that the type of value in a choice list can be better specified and hope to improve this.

[MichaelBrown4]

This has broken a few questions in many forms I have out for our teams to use.  We have a select_one and a select_multiple pulling from a choice list that has values like "00", "09", "10", etc.  I'm able to do the null/calculate field trick just fine for the select_one question, but not sure how I can fix the select_multiple.  It should be creating a string like "01, 04, 10, 99" and is instead creating "1, 4, 10, 99".  Do you have any suggestions on how to fix this?

Besides me, others at my company had field teams and others working where these kinds of values get used in downstream automation workflows that essentially broke when this happened.  Is this something that will be logged as a BUG going forward or something the users need to work around correcting?  We need to decide if we should be investing in making changes to our automation code to handle this or if we can wait/limp along until a formal change is pushed out.

Thanks for all your help and responses around this.

Mike

[Anonymous User]

We are in the same situation - we have a survey with external choices that relate to an Oracle table.  With the latest updated app, I now have to manually fix the data before it can be synced to the Oracle table.

I agree that this should be noted as a bug.  Looking forward to a solution to this one.

Thanks as well for the support and responses from Esri!

Eric

[GianniCampanile2]

Hi all,

I followed James Tedrick's suggestion and modified the Survey, but in one case it was not possible. We are now watching and modifiyng data manually, and we are thinking about developing a Python daemon that does the same job. We also considered triggers and SOIs , but the decision to go with this effort depends on the time for the patch/new version to be released.

Gianni

[TexasMike]

This is a headache for us.

[DrewMoffitt]

Add me to the list of "please consider this less of a bug and more of show-stopper."