Can I have the same field name in Parent and Repeat child?

2175
11
03-06-2020 10:14 AM
DougBrowning
MVP Esteemed Contributor

In my forms I like to pass our PointID down to each repeat table for ease of viewing.   Since it is a separate repeat table using the same name should technically be ok.  But of course the excel form in Connect is yelling about it.

It seems like I can still publish but am I headed for disaster here?  I was going to change the repeat field to PointKey but I have a form with 3 repeats now so that would get weird.  PointKey1, PointKey2, etc.  It would be a mess when moving data to my backend SQL.

Then the other issue is if I have the repeat also use PointID with a calc of PointID from the parent it gives an error.  So I guess I need to use PlotKey no matter what?  But could I still use PlotKey in all 3 repeats?

Anyone try having a parent and child with the same field name?  Is there any official guidance on this?

Thanks a lot

11 Replies
DougBrowning
MVP Esteemed Contributor

Adding to this I would also like to have 2 repeats that have identical field names.

We collect Plants on the left and right bank of a stream.  So both repeats should have the field Species.  Having one be called LeftSpecies and the other RightSpecies makes no sense.

thanks

TL2
by
Occasional Contributor III

I support this idea.

PaulPetersen1
Occasional Contributor

@DougBrowning , I'm going up against this issue right now...did you ever find a sustainable solution? I've just been adding prefixes to shared fields names in the children to make them unique, but I really don't like doing that.

0 Kudos
DougBrowning
MVP Esteemed Contributor

No I am adding prefixes as well.  We have other transformations on the data to match the backend schema anyway so just another one to add.

What I do is in Python I load the feature class or table into memory, then do add field and copy the value over using calculate field.  Then run append and it all matches up.

Another idea is to add the field to the service directly after you publish.  Then run a script each night to copy the value over.

Hope that helps.

0 Kudos
PaulPetersen1
Occasional Contributor

@DougBrowning , thanks. Glad to know I'm not crazy at least. The only other thought I've had is that in my case I'll be launching Survey123 from Field Maps and thus can pass the attributes in question from Field Maps to Survey123 via URL. So I'm thinking I can create some temporary hidden fields (with null schema), load the attributes into the temp schema from the URL, and the calc the values into my field schema within the various repeats (thus avoiding using a duplicated field name within a calc, since the temp field name is unique). I haven't tried it yet, but think it should work...

0 Kudos
DougBrowning
MVP Esteemed Contributor

Note sure I get what you wrote but You cannot dup a field name anywhere in the form though.  The entire form and all repeats must not use the same field name twice.

0 Kudos
PaulPetersen1
Occasional Contributor

It seems that I can duplicate a field name in the form, as long as I don't reference that field name in calculations, defaults, relevant, etc. It highlights the field in pink, but doesn't actually stop me from publishing and collecting successfully. My prototype setup is in the screenshot below. Basically I write values to a null-bound temporary field and then use the temporary field to calculate the duplicate fields. It works in my testing so far...the method allows me to write the same value to duplicate field names within the form.

PaulPetersen1_0-1647279170482.png

 

0 Kudos
DougBrowning
MVP Esteemed Contributor

Calcs may not work right however.  Also uploading.  Maybe 123 can chime it but good chance something else will break.

0 Kudos
MichaelMannion
New Contributor III

Our team recently encountered this same issue regarding duplicate column names. This thread was one of the resources I used while diagnosing the problem and describes the behavior well, so I'm posting a solution that Esri shared with us, for posterity.

Firstly, some disclaimers: I'm a Survey123 novice, so I'm only able to speak to our particular use case, and may be omitting some details or discussion of broader implications that affect others. Also, I don't speak on behalf of Esri; if anything below requires correction or official confirmation, please defer to any subsequent posts from their staff.

To the topic at hand, during our Survey123 project we learned that:

  1. Having duplicate question names in different sections is supported, despite the red highlighting in Excel
  2. Referencing those question names in calculations requires a special syntax

Regarding #1, we are building a survey from a feature service based on an enterprise geodatabase. In this case, the question names (Column B, "name", in the Excel survey editor) match their corresponding column name in the target service/geodatabase. These names are unqualified (i.e. just the column name, with no table/schema/etc.) and cannot be changed.

Our geodatabase data model has many standardized column names. Therefore, when building a survey that includes related tables, we end up with questions that have duplicate names in the various survey sections (main section, repeat sections). This causes the red highlight in Excel.

Fortunately, for a simple survey, you can safely ignore the red highlighting and publish the survey with the duplicate names. Survey123 knows how to differentiate them based on the context of their respective sections.

 

Knowing this, the issue for us then became #2 above. The standard syntax for referencing a question in a calculation is ${QuestionName}. If you have multiple questions named "QuestionName", those calculation references are ambiguous.

Luckily, there is an alternative syntax for referencing questions in calculations that identifies them unambiguously, even if the questions have the same name: you can specify a path to the question. Our contact shared this doc which explains it in more detail. In a simple example, consider a survey with:

  • One question in the main section called "Name"
  • One question in a repeat section called "Name"
  • A calculation in the repeat section that concatenates the values of those two questions

MichaelMannion_0-1665528054820.png

Observe that the calculation uses path names to reference the two questions:

/Form_4/Name
/Form_4/HYDRO.Asset/Name

where:

  • "Form 4" is the name of the survey / Excel workbook
  • The leading part of the path for both questions is "Form_4", with an underscore instead of a space
  • The name of the repeat section, "HYDRO.Asset", is included in the path to its question

Testing the survey in Survey123 Connect shows that the "Calculation Test" question correctly concatenates the two name values:

MichaelMannion_2-1665528470674.png

 

Our team's Survey123 SME has confirmed that this same approach works with our actual (i.e. more complex) survey, so we are moving ahead with this as a solution.

The benefit for us is that we do not need to physically rename any columns in our underlying geodatabase. That allows us to follow existing organizational standards; facilitates geodatabase use for non-Survey123 users familiar with those standards, and; avoids complex data model migrations in the future if we add new calculations that reference duplicate column names.

HTH