Nested repeat with repeat_count shows Add records box now?

[DougBrowning]

Is this new for nested repeats with a repeat count?  It loads all 4 the first time but the next few it loads 1 and a box the user has to tap for the rest.

First one

Rest

Thanks

[Anonymous User]

Hi Doug,

Are you using the Inbox or editing an existing sent survey, or collecting a new survey? I assume this only happens in the nested repeat and the repeat count is referencing a value from within the parent repeat, not the parent layer, or are you using a static value?

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

Phil.

[DougBrowning]

It is a static value for the repeat count actually.  It is in a new collection.  I just tried 3.6.137 and it still does it.  I will email the form.

Thanks

[Anonymous User]

Hi Doug,

Finally got some time today to take a look at your survey. I am not able to reproduce the issue you are seeing. I tested with 3.6 and when the form is opened via a new Collect and I navigate to the repeat records page, I see all 21 repeat rows created for Transects, and then I see 4 repeat rows created for Human and created for each of the 21 rows. This is the correct and expected behaviour based on your form logic, and I can see the rows being created in the sqlite database when the form is being initialised.

The reason you see the “Add 3 records” option is that only 1 record has been created in that parent repeat, but 4 are set by the repeat count, so the app knows there is a mismatch is and giving the option to manually add the 3 extra rows to match the repeat count. This usually happens when you are using existing feature services or editing a survey via the Inbox or Sent items, and there is a difference between the actual number of repeat records in the repeat table and the repeat count value.

The only difference in my testing is that you didn’t provide the csv files used in the pulldata() calculations. If you can send me those files as well, I can do some more testing based on actual values in the survey. It could be that some of the calculations or relevant expressions used that rely on the pulldata() values are causing an issue when the form is initialising that stops the 4 repeat rows getting created successfully for each parent record. Need to investigate that further.

Regards,

Phil.

[Anonymous User]

Hi Doug,

Got the additional pulldata csv files. The problem is actually the calculation inside the nested repeat that is based on a value in the parent repeat and due to the order of operation and load sequence it causes values to be nulled out incorrectly when waiting for the value from the parent, so the calculation does not run which stops the remaining records in that repeat being created automatically. If you remove this calculation everything works as expected.

The “Add 3 records” prompt is an enhancement that was added in an earlier release to prompt that user that a static repeat count was set by the author, with a set number of repeat records, but currently the repeat does not have the same number generated. That was the user can easily add the additional records.

We have a similar internal issue in our backlog to improve nested repeat handling when repeat count and a calculation referencing a value outside the nested repeat are used. I would encourage you to submit this issue as a bug via Esri Support. Our Support team will assign an official bug number for your records. This number can be used to search for and subscribe to the bug on the Esri Support site. If the issue is reported by other customers it will be attached to the same bug report.

The only way to work around at this stage would be to not have the calculation in the nested repeat reference a value outside the nested repeat, especially if you are wanting to use repeat count on a nested repeat, until this issue can be fixed and released in the future.

Regards,

Phil.