Remove commas from Integer field type

7310
12
10-11-2017 05:39 AM
Lake_Worth_BeachAdmin
Occasional Contributor III

I have a field for 'phone number' that's integer type because I want to force numbers by the end user and not allow letters. however the once the numbers are entered they appear with commas ad the values in AGOL (5,546,433) for example. 

How can I remove these commas within survey123 .xls sheet? is there another parameter I am missing. 

Tags (2)
0 Kudos
12 Replies
BethanyBerry
New Contributor III

So it sounds like the issue is when you visualize the data in ArcGIS Online after publishing the survey. Am I correct in that?

If so, when you add the hosted feature service to the web map you can configure the popups such that the 1,000's separator is removed. That workflow is detailed here (easiest just to do a CTRL + F for "1,000"): Configure pop-ups—ArcGIS Online Help | ArcGIS 

However, another workflow you could look into is setting the field to be a text field and then using a constraint to not allow letters. The way I set this up required a bit of creativity. In the constraint column, I used ".>1000000000" (thereby assuming that all phone numbers will be greater than this, 100-000-0000). So entering A999999999 would not work, because it is still not greater than 100-000-0000). Then to avoid confusion, you can just add something to the constraint message column for that field prompting them to enter only numbers.

Hope that helps!

Lake_Worth_BeachAdmin
Occasional Contributor III

Thanks Bethany, I went with the 2nd option, its working as intended now.

0 Kudos
by Anonymous User
Not applicable

It looks as though they have an input mask just for obtaining a phone number

Esri custom columns—Survey123 for ArcGIS | ArcGIS 

Scroll to the bottom of the web page and you will see this table

deleted-user-qpvAI3Fo0MKR
Occasional Contributor III

I have a Survey123 form that's behaving this way as well - we're capturing zip codes and street addresses and commas are being inserted into these fields by default. I've adjusted the pop-up to preclude the commas, but I'm hoping there's a setting I can apply to ensure commas aren't added when the users are filling out the form to begin with.

FYI, the field type in XLSForm is integer.

The workflow is to export to .csv from the attribute table, and then to use a combination of Microsoft Excel and Word's mail merge function to create form letters based on the data the users are gathering; we need clean addresses without commas for mailing labels to print correctly. I realize we can always use the find and replace function once the data are in Excel, but I'm hoping to skip this step.

Any thoughts?

0 Kudos
BrandonArmstrong
Esri Regular Contributor

Hi Joshua,

Have you considered using a 'text' field type in the XLSForm as opposed to integer?  Please explain if this would not work for you as a solution.

Thank you,

Brandon 

0 Kudos
deleted-user-qpvAI3Fo0MKR
Occasional Contributor III

It would work yes, but I see this as a workaround as opposed to treating the root issue. Street Numbers and to an extent Zip Codes are factually whole numbers, they are not text. The commas are nice to have in popups, but this should be an option the user chooses to implement, and not something placed by default and definitely not something stored in the attribute table.

Just my $0,02

MichelleWilliams1
Occasional Contributor III

I'm doing something similar, I have work order numbers that aren't the same pattern, but I'd like the keypad to come up on the device. Any advice would be helpful.

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Michelle,

One possibility is to use the appearance 'numbers' with the survey - this will display a numeric keyboard in-form. 

BrandonArmstrong
Esri Regular Contributor

Hi Joshua,

Although, on first take, it does seems that an integer type field should satisfy for all ZIP Codes and Street Addresses there are some cases that must be considered.  For instance, some ZIP Codes start with a leading '0' (CT, MA, MA, NJ, etc...) and lots of addresses include '1/2' in them i.e. 920 1/2 Church Street.

Due to examples like these, in fact, ZIP Codes and street addresses should be stored as strings, or 'text' type questions.

Brandon