S123 and non-unique database field name (existing feature service)

[JimmyKnowles]

I'm developing an S123 form using an existing feature service that has a common key in three related feature classes. The field name is the same, but they are in different feature classes. The Survey123 documentation states:

• The name column determines the name of the ArcGIS feature service column in which the response to the question will be stored. No spaces or special characters are allowed in this column. No two rows can have the same content.

The feature service also has relationship classes using globalid-guid and takes advantage of this. There are several reasons why we use this common key. One is in this thread related to parent-grandchild relationships. My latest reason is for wanted to use the batch attribute editor widget in WAB. This requires that fields have the same name if you want to batch edit the same field in different feature classes.

I know this is possible because I did it...the xlsform give a warning by highlighting the cells red, but otherwise it publishes just fine and collects data without any issue. But I'm just curious if this is likely to be possible in the future. In other words, is it probable that future releases will make this no longer possible. 

[Anonymous User · Accepted solution]

Hi Jimmy,

As per the documentation, having two field names with the same exact name is not supported by Survey123. This will not be supported in future either and is a known limitation for several reasons.

Whilst you may have been able to successfully publish the survey, note there could be issues with submitted data to these fields via the field app and web app, and issues when trying to modify the survey and republish, or issues when trying to use the Survey123 website and some of the analysis and feature reporting tools. Therefore is it not recommended to publish surveys that contain two questions with the same name field.

Regards,

Phil.

[JimmyKnowles]

Hi Phil,

Thanks for the info. Since it allowed me to publish the survey, I was just curious if maybe this was allowed/possible, but not recommended or advertised. We'll figure out a different way to implement this to avoid any issues in the future.

Jimmy

[MichaelMannion]

---

This will not be supported in future either and is a known limitation for several reasons.

---

@Anonymous User  would you be able to elaborate on the "several reasons" and why a future fix for this limitation is not forthcoming?

For context, I'm working on a multiyear project during which we've invested considerable time (hundreds of person hours) standardizing column names in our geodatabase models. One advantage is that when users open a new table, they already know what most of its columns mean without having to refer to the metadata; semantically equivalent columns have the same name across all of our tables. This investment in standardization is also streamlining new development; data modelers can choose many columns in their tables from the existing list of standards.

We're now introducing Survey123 into this environment, and finding that we have copious name conflicts when working with related tables. I'm relatively new to Survey123, but from talking with my colleagues and reading the documentation, I understand that our only recourse is to change the physical column names in the enterprise geodatabase to be unique across all tables used in the surveys.

It strains belief that column names must be globally unique throughout our geodatabase. This is akin to requiring that every file on your computer has a unique name, regardless of its directory. Or, that all variables names in your code are unique, even among different functions and imported libraries.

There are well-defined namespaces in the database (i.e. table names) that the other ArcGIS applications respect - Server/Pro/Map/etc. know that table1.name is a different column than table2.name. I'd like to understand why this is not also the case for Survey123.

I'm hoping that I'm just misunderstanding, and that there is still a workaround that I have yet to discover. Thank you in advance for any additional information you are able to share.

[MichaelMannion]

Esri helped us with a solution, which is summarized in a post on another thread.