nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

dougbrowning

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

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

dougbrowning

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

TLongSUGF

I support this idea.

PaulPetersen1

@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.

dougbrowning

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.

PaulPetersen1

@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...

dougbrowning

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.

PaulPetersen1

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.

dougbrowning

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

MichaelMannion

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:

Having duplicate question names in different sections is supported, despite the red highlighting in Excel
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

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:

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

MichaelTorbett

@MichaelMannion Thank you for this information. I just incorporated it into one of my surveys tied to an Enterprise Geodatabase that has related tables with the same field names. Have you ran into any issues with using the path names in your calculation fields? I'm having an issue where my fields aren't calculating if they are tied to a relevant question, but I think this might be a bug in the the latest 3.16 update.

MichaelMannion

The short answer is "no", but the real answer is that I don't have enough first-hand experience to know the answer to your question. I've only learned enough about Survey123 to understand how it impacts our data model and infrastructure; we're fortunate to have a dedicated Survey123 team member building our production survey.

Hopefully someone with more practical Survey123 experience can comment. Sorry!

KayleeRivera

Replying here 2 years later with some additional tidbits that I just discovered after using this comment to solve an issue 🎉

Any groups or repeats that your target field is nested under also need to be named. So, for example, you could have:

/Form_4/my_group/Name
/Form_4/HYDRO.Asset/another_group/Name

We found that a quick way to access these XPaths without having to guess & check. With your survey open in Survey123 Connect, click the Files button on the left. Open the XML file in your text editor of choice. Ctrl + F to find the field name that you're looking for in the section with the bind tags. Copy the value from the nodeset parameter (no quotes).

Thanks for the initial post @MichaelMannion!

EricaNova

@MichaelMannion thank you SO MUCH for sharing this information, I wish I'd read this years ago!

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.