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,
Hi @KatharinaWerner1,
Yes, this has been fixed in the upcoming 3.13 release which will be available this week.
It was originally logged as:
BUG-000138199 - Leading zeros are dropped from the values submitted by the 'select_one' questions in ArcGIS Survey123 3.12.
Please test out your workflow with the latest 3.13 release and let us know if you still encounter any issues.
Regards,
Phil.
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)
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!!
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
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:
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.
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
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
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.
This is a headache for us.
Add me to the list of "please consider this less of a bug and more of show-stopper."
Hello, is there an update about that bug? We're using a csv-file as source of the choice-list. So I guess the workaround doesn't work for csv-file.
Thanks, Katharina
Hi @Anonymous User,
thanks for your answer. That sounds really great. I'll test as soon as 3.13 is available in Google Play Store. As I read it should be released today? 😁 (ArcGIS Survey123 Deprecation Notes (May 2021) (esri.com))
Katharina
Version 3.13. works fine for us! Thanks and have a nice weekende,
I am concatenating text fields (defined as string and have an input mask such as '999') that can contain leading zeros. While the text fields retain their leading zeros, once they are concatenated the leading zeros are dropped. Example: field1=080 and field2=009, when concatenated with a "-" between the two fields the result is 80-9. I need it to be 080-009. Any suggestions?
@IsmaelChivite @JamesTedrick
It sounds like toFixed should be built into Survey123 connect forms for this issue
@RM_-_AmyOrtner__GISS_ It would be great if you can share an XLSForm to illustrate the problem. I created my own XLSForm based on your description and I do not lose any leading zeroes.
Attaching animation with the behavior I see and the XLSForm I used.
@IsmaelChivite
Could this be used for necessary trailing zeros? Or maybe the question actually would be:
I am working on a form with a geotrace field, utilizing calculated lat/long information. I am running into some instances in the calculations where the ending number is a "0", which gets cut off in my form.
Is there a way to utilize the toFixed functionality built into the feature report within a survey123 form? or some kind of function/restraint/calculation i can utilize?
@IsmaelChivite @JamesTedrick @TonyDaSilva1
Reverse Engineer Ismael's first response below:
https://community.esri.com/t5/arcgis-survey123-questions/survey123-leading-zeros-for-integer/td-p/806983
Ismael, shortly after posting my problem with the leading zeros, I found a way to make it work. I'm not sure exactly what I changed, I think it may have been defining the field type as string, but it has been working. Here is what the xlsx looks like now.
This also works with Type=text, appearance=numbers, and bind::esri:fieldType=esriFieldTypeString.This way you have the little calculator for input as well!
The bind:esri:fieldType did not do the trick, but setting just the 'bind::type' column value to 'string' has allowed me to preserve my leading 0's in my integer question. I have not tested this on any select_one or select_multiple questions, however.
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
