Index on nested repeat

[DouglasKnabe]

I've got a nested repeat, and am trying to create an index on the inner repeat that rolls over from the previous outer repeat. (see table below) I've got a field ${repindex} using position(..) within the inner repeat, a field (${currMax}) equal to max(${repindex}) in the outer repeat, then a sum(${currMax}) outside the repeats, which is then referenced in the display of the inner repeat. It doesn't quite work as intended, especially when I cycle back to previous repeats. Any ideas?

i.e.

Outer repeat Value	Inner Repeat Value	rollover index
a	4	1
a	2	2
a	6	3
b	3	4
b	2	5
c	1	6
c	7	7
c	8	8

Ideally, the rollover index would recalculate if a record is added or deleted in the middle.

[DougBrowning]

One trick to not recalc on you is once(position()).  But note position has issues when it is nested.  Check to make sure you are not getting a loop error at the top right on Connect.  If you do I had to go back to the old way of once(count(dummyfield of 1)).

To get the sum or max correct it has to be 1 level above what you want to count.  It does get tricky in nested.  But just roll up as you go.

But big note all of this falls apart if the user goes back a few records in the repeat and deletes a record.  Then you got a dup.  We mostly just stopped using indexes.  In an attribute table they order how they were added anyway so we just don't really need them anymore.

[DouglasKnabe]

Thanks. The index is more for display to help line up with what is currently a paper form that we are transcribing via Survey123. The nested repeat is more to add convenience, so I may just give the end user group an either/or choice.

[abureaux]

This could also be a case of poorly formatted calculates. Once() would likely still help, but restructuring the calculates could be a better option. Any chance you can include the XLSX?

EDIT: Also, what is the intent here?

[EvanR]

@DouglasKnabe, I needed to do the same thing (track the cumulative number of records inside a nested repeat). I tried various approaches, but eventually came up with a method that seems pretty robust, even if you move backwards through repeats or delete records from the middle. It requires four separate questions and a JavaScript function.

Outer repeat:

• Question that calculates the number of inner repeat records in the current outer repeat record. I usually do this with count() on a primary required question, so that records only count once that field has been populated.
• Question that keeps a comma-separated list of the values from the first question (list of inner repeat totals within each outer repeat), with one entry for each outer repeat record. I use join(", ", ${name of above question}).
• Question that uses a JavaScript function to calculate the sum of values in the list generated by the previous question. This returns the desired global/cumulative index for the current inner repeat record, across all outer repeats.

Inner repeat:

• Question indicating that a record should be included, used in the count() for the first question.

Adding "calculationMode=always" in the bids::esri:parameters field for the first two questions makes the third question less twitchy; your results may vary. I have attached a stripped-down testing survey.