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; } } }

Repeating Groups that are not relevant still write to the tables

RussellSturm

Is this by design or a bug? Here is an example that is causing some heartburn. In a survey I have a repeating group that is conditionally required. If the user doesn't need that section it is not shown. However I am still seeing a record being inserted into the table. If the repeating group is not relevant I wouldn't expect it to insert a record into the table.

To explain further here is our example. The questions in the repeating group are related to how many plants were counted in the sample and how many plants were found in the sample that are affected. i.e. They count 500 plants and found 2 with the condition we are looking for. We default the values of those questions to aid with user entry to 500 and 0 respectively. When the record is inserted for the repeating group that is not relevant it inserts the defaults of 500 and 0. Then, when I look at the data it makes it appear that they did the counts and found 0 affected plants.

From my testing I am seeing this behavior in 3.3 and beta versions of 3.4.

Trouver plus de publications taguées avec

Accepted answers

All comments

Anonymous User

Hi Russell,

This is a known issue with loading default values into a question that is not relevant on load, applies to parent layer or repeats. In this case the default value is stored in that question and sent to the feature service. In your case, because the default values are inside the repeat it is creating the first repeat record to be able to populate it.

There is a currently a open support bug BUG-000097105 in our backlog for this issue but unfortunately it did not get fixed for 3.5.

Have you tried setting the repeat appearance to minimal, which should avoid the first record being created automatically?

Phil.

RussellSturm

Thanks Phil. I think if I move my default values to a calculation I can get the survey to do what I want.

However, another related question. When I moved my values to the calculation it does not write a record to the repeating group table. But I have another repeating group that does not have any default values and it always writes a record to the repeating group table. The record has no values besides the global keys and created/updated info but I'm curious why one is creating a record and the other isn't. Are there other conditions that cause it to create a record? I have both of the repeating groups set up in the same way.

FYI - The all "null" record I can workaround pretty easy (unlike when the defaults were being inserted) but if I could avoid having the record at all I would rather have that.

Thanks!

Dirk_Vandervoort_1-1730590309566.png

Anonymous User

Hi Russell,

There must be an expression (could be required, constraint, relevant, pulldata etc) in that repeat that is running when the form loads based on other values changing or being loaded. This is what creates the first record.

Have you tried setting that repeat to minimal appearance?

Can you share your xlsx file so we can take a closer look?

Phil.

Anonymous User

Hi Russell,

The issue with default values populating when a question is not relevant has been fixed and you can test it out with latest 3.6 beta builds available on EAC. The latest version to test with is 3.6.100. Please let us know your feedback.

Regards,

Phil.

IsmaelChivite

Russell Sturm‌ The fix is now available in 3.6. See https://community.esri.com/groups/survey123/blog/2019/09/26/hobbit-day-release-36

NirmalOjha1

@IsmaelChivite , @JamesTedrick

I am having the same issue, but with the latest version of the Survey123 Connect version 3.12.232 (latest available).

Did the "BUG-000124014" resurfaced? I am getting lots of empty records being submitted.

Nirmal

Anonymous User

Hi @NirmalOjha1,

Can you please share your xlsx file so we can take a look at how it is configured and confirm if it is the same issue as BUG-000124014? Can you also share details of which question and the workflow to reproduce it.

Regards,

Phil.

imbachb_1-1780658660866.png

NirmalOjha1

Hi @Anonymous User

I will send you direct message with the XLSX file attached.

Thank you.

Nirmal

Anonymous User

Hi @NirmalOjha1,

I took at a look at your survey and narrowed down the issue. It is caused by the required fields inside the nested repeats. There is a known issue if required fields are used inside a nested repeat and the repeat is also not relevant, a blank record will be created/sent to the feature layer. If you remove the required "yes" values from those questions inside the nested repeats, blank rows will not be created when the repeats are not relevant.

We have two existing support issues BUG-000127740 and BUG-000127759 which are related to the same issue, they have the same sympton and cause related back to required fields or other expressions in nested repeats.

Regards,

Phil.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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