Bug with missing data in nests

3508
39
08-24-2018 01:12 AM
ClaireWood
New Contributor III

Hi,

I have been made aware of a bug where relevant questions are not displayed in the first record of a repeat, if accessed from the Drafts, Sent or Inbox.  This means data recorded in the first nest of repeats is potentially going missing unless it is submitted straight away.  Could you let me know when a fix will be released for this as it is a big issue for us.

Many thanks,
Claire 

Tags (1)
39 Replies
by Anonymous User
Not applicable

Hi Claire,

Just an update to let you know that we have been working on the issues described above and a lot of progress has been made with repeats/nested repeats and defaults/calculations/relevants/groups and missing values when opening the survey, so we believe the issue has been resolved for our upcoming 3.2 release. 

 

If you have time, can you please check out the latest 3.2 RC builds (Connect 3.2.192 and App 3.2.262) available on EAC here: Welcome to our Feedback Community and provide any feedback. The sooner we can get feedback the sooner we can address any outstanding issues before the release.

Regards,

Phil.

0 Kudos
by Anonymous User
Not applicable

Just commenting to for updates on when this will be fixed, we are experiencing the same issue. 

0 Kudos
LynnBerni
Occasional Contributor II

There are multiple threads on this same topic.  I'm having the same problem. Data in first repeat is lost when the survey is reopened from Drafts or Outbox. It's only data in relevant fields, and all are referenced within the repeat. The repeat also includes a date/time field, with default set to now(). That gets reset too, to the current date/time (ugh).

 

I just saw the blog post Minor Update to Survey123 Available (August 30, 2018), which states that this problem has been resolved.  So I:

  • confirmed that we are on the latest version of the ios app (3.0.149)
  • installed the latest version of Connect (3.0.142)
  • republished surveys
  • downloaded "updated" surveys to ipad

 

Nada.  It's still deleting/resetting relevant fields in the first repeat.

I don't know if this was happening prior to 3.0.

0 Kudos
by Anonymous User
Not applicable

Hi Lynn,

Would you be able to share your survey, out of interest, do you have a repeat_count in your survey for the repeats?

In addition to my comments to Claire, does your survey contain relevant statements inside repeats that reference questions outside of the repeat?

Phil.

0 Kudos
LynnBerni
Occasional Contributor II

Hi Phil,

I am not using a repeat count and the relevant statements are referencing questions *inside* the repeat only. 

Here's a link to my XLS form.

Thanks!
Lynn

0 Kudos
by Anonymous User
Not applicable

Hi Lynn,

Thanks for providing your survey. The issue you are experiencing is similar to the issue that Claire has, however is being triggered by a different configuration. The relevant statements you are using inside the repeat are based on a note question type inside the repeat, and based on the current implementation for note question types, they do not re-trigger relevant statements on the attached questions. I have logged this as a bug and we will aim to fix it in a future release.

In the meantime, if you change the note field to a read only text field, I believe it will work as you are expecting. I tested this with latest version of the app and beta release and the values were present when opening from Drafts or Inbox.

I found an issue with your survey which you need to fix, on the begin repeat question, you do not have a "query" clause, this means no records are ever queried and downloaded from the Inbox. See above comments above regarding this: https://community.esri.com/message/800823-re-bug-with-missing-data-in-nests?commentID=800823&et=watc... 

Also I see you are using null esri field types on the MILEAGE, TC_concat, ECOLI_concat fields, in this case the values are never stored, so will never been seen in the feature service or when opening survey from Inbox, they will always be null.

Hope this helps.

Phil.

0 Kudos
LynnBerni
Occasional Contributor II

Hi Phil,

Thanks for the feedback.  Per your suggestions, I changed the SITEID note field to a read-only text field (in fact, I changed all my calculated notes!). In the bind::esri:parameters field for the begin repeat question, I had allowUpdates=true.  I have now changed that to query allowUpdates=true allowAdds=true.

 

I republished and retested my survey, but it did not solve the problem.  I also tried changing the syntax to include a "=" after "query":  query=allowUpdates=true allowAdds=true.

That didn't work either.

Btw, it would be helpful if Prepare for editing existing survey data—Survey123 for ArcGIS | ArcGIS  was a bit more specific about the correct bind::esri:parameters syntax for repeats. Based on what I had read there, I thought that allowUpdates=true was correct.

Please advise, thanks!

Lynn

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Lynn,

allowUpdates=true is the correct syntax, however the query= is incorrect; you can have either query by itself (to indicate the default of 1=1) or query=<a DB query to select which records are displayed>.  

0 Kudos
ClaireWood
New Contributor III

Hello,

I am still experiencing problems with losing data from repeats with questions with relevant clauses set.  I have been testing the St Kilda Penguin release, and still have issues.

The issue I had above was related to questions inside repeats having a relevant clause set, based on a value outside the repeat.  I have worked around this by removing the relevant clause from questions inside the repeat, which appears to work.  However, I have a similar survey, which has questions with a relevant clause based on a value from inside the repeat - and again am losing data from the first repeat when loaded from the Drafts/Outbox.  

I have attached the xlsx form, the issue occurs in the repeats on page 4.

Best wishes, Claire

0 Kudos
BrandonArmstrong
Esri Regular Contributor

Hi Claire,

The behavior you are encountering, with the data not appearing in repeats after the first, when there is a relevant clause applied to questions within the same repeat, has been raised in our internal backlog. We are currently investigating the cause. I will take a look at your XLSForm and confirm whether or not it looks to be the same behavior that you are encountering and will update this thread with more information if it appears to be something different.  In the meantime, can you please confirm that the actual data is present in the feature service, and that this is a display issue as is the case with the previous issues listed?

Thanks,

Brandon