Inbox data retrieval fails for some nested repeats, but not all

[CarlBeyerhelm1]

My survey has a somewhat complicated data model, as illustrated below. Each of the 9 nested repeat elements are made relevant by choices made in the the repeat's parent.

When I open a survey from the Inbox, all of the nested repeat data are present, except for the OBS_POINT, OBS_LINE, and OBS_POLY layers.

Each of the repeats includes a value of "query" in the begin repeat question's bind::esri:parameters parameter.

The OBS_POINT, OBS_LINE, and OBS_POLY data do appear in the corresponding hosted feature layers, so I know that data capture and sync have been successful, but Inbox data retrieval for the OBS_POINT, OBS_LINE, and OBS_POLY layers was not.

The survey's XLSX is attached.  Any insights would be appreciated.  Thank you.

Data retrieval via the INBOX was successful for yellow-tinted elements, and failed for the blue-tinted elements.

[DougBrowning]

My guess is the underscores in the table names.  Underscore is a special char in SQL queries so it could be missing up the inbox query.

hope that does it

[CarlBeyerhelm1]

Thanks for your reply, Doug.  Unfortunately, removing underscores from the 3 OBS feature layer names was not a remedy.  Plus, the SITE_POINT, SITE_LINE, and SITE_POLY feature layers higher up in the schema contain underscores, and they are successfully returning data to the Inbox.

I don't know if it is related or not, but there is something funky going on in the OBSERVATIONS and INDIVIDUALS repeats, because default values that I've set do not appear in the first record of a repeat, but do appear in subsequent records of the repeat.  It has me stumped...

[DougBrowning]

Oh yea now I see that sorry.  They are the only double nested repeats though.  There may be some bugs with double nested repeats like that.  Not sure but may be posted.

[CarlBeyerhelm1 · Accepted solution]

Yeah, I looked around quite a bit, but couldn't seem to find much guidance on best practices, or issues, in double repeats.  In my case, the OBSERVATIONS table is parent to the OBS_POINT, OBS_LINE, and OBS_POLY repeats, as well as the INDIVIDUALS repeats, so it is a bit convoluted.

Anyway, I incrementally tested each parameter in the OBSERVATIONS repeat, and discovered that OBS_POINT, OBS_LINE, and OBS_POLY data can successfully be retrieved to the Inbox if I remove the value of 1 from their repeat_count parameter. I had wanted only one spatial feature to be recorded for each observation. The cause-and-effect between a repeat_count limitation and failure to retrieve Inbox data is a mystery to me…as are many things. HA!

By removing the repeat_count limitation, however, I had to add a constraint parameter like count(${OBS_POINT})=1 or NULL to avoid exceeding 1 feature per observation. It does the trick, but you actually have to create/accept the second feature before the constraint kicks in, at which point you have to delete the second feature...which is kind of clunky.  So, I'll put this fix in the category of a work-around, but not a clean solution.

Thanks for weighing in.

[DougBrowning]

Ohhh repeat count!  Yea that one will get you for sure.  Sorry I totally missed that.  It has issues in the loading from inbox and basically wipes your data.

Yes use a constraint is what I do.  Got burned too many times on repeat count - esp with a formula.  I got a post on it here somewhere.  I have a message in red come up that says Opps went too far please delete to help the user since its weird.  You have to let 2 get created, then the message, then they delete it.

Sorry I missed that.

[CarlBeyerhelm1]

No worries, Doug.  It's comforting, I suppose, that other people have hit the same hurdle...so it's not "just me"!  ;>)