Crashing leads to only data from the first page of a survey getting submitted?

[AlfredBaldenweck]

Hey all,

I'm submitting a support ticket for this, but I'd like to see if anyone else has been experiencing the same thing.

I have a three page survey. We're experiencing major crashes and micro-crashes.

• Major crash: The field application closes unexpectedly. Upon re-opening, the user is prompted to continue where they left off.
• Minor crash: After backing out of a saved draft and going back into it, they open to a blank page. They are able to move to page 2 and complete the survey.

In both cases, the end result is the same: they successfully submit the survey, but only data from the first page is submitted. 

This is EXTREMELY problematic, as frequently this is across several surveys and repeats miles apart from each other. 

Has anyone else experienced this? 

I'm wondering if it would be fixed by removing the pages and having it just on one long page, but the user experience for that would suck; this is a very long survey.

[CodyPatterson]

Hey @AlfredBaldenweck 

I had a few instances of the Major-crashes you're describing, I ended up finding that it was due to a repeat table inside of my survey, which I had removed to fix it. If there's a for-sure way to intentionally replicate a major or minor crash, I would rebuild a test survey from the ground up, and add one section at a time to see if you can replicate it.

Cody

[AlfredBaldenweck]

Unfortunately, I can't replicate on demand, which is why the last support case ended. I have a nested repeat on page two. I cannot remove the repeats without having to completely rethink the entire workflow.

In my own experience, I'll get the crash towards the end of page two, but I often don't have any crash at all. My user took it for a heavy spin yesterday and basically got only two usable surveys out of the 7 she did.

It's weird because after a crash, I'll still have the data on page 2 from before the crash when I reopen it, but it's like the entire record became unmoored from itself so anything I do just floats away into the ether.

The general format is:

• Page 1: Main table
• Page 2: Repeats
• Page 3: Main table: finishing up
• Main Table: Questions with no assigned page, meaning they float on all pages

Only page 1 ever gets submitted for me.

[ChristopherCounsell]

Can you share your XLSForm?

What version of Survey123 Connect was used to publish the survey, and what version of the Survey123 field app?

Do you have logs from the field app?

Do you have any additional information around the workflow up until this point? Like high volume of submissions, device type, literally anything?

Did the issue only start occurring recently? 

[AlfredBaldenweck]

Yeah, I have a log and the Excel form.

I'll attach the form here. Not sure what all information is in the log so not sure if it's something that can be shared publicly. Sorry that it's kind of messy, but it is very long and there's a lot of stuff happening in it.

One thing that I think might make a difference and I'm going to try is that I have the pages set up by relevance, rather than by body::esri:visible. I'm making the switch and going to ask my user to test it.

Happens on iOS and Android. Been happening a bit here and there through testing over the last few months of development, but I haven't been able to make it happen for weeks, and then my user had 5 in the same day while putting it through its paces. And of course, I can't replicate on demand.

On a related note, Survey123 really needs logging to be a permanent setting.

[Neal_t_k]

You have some duplicate fields.  Might be causing issues when both are relevant. Obviously they are in different tables, but I try to avoid any duplicate field names.

[AlfredBaldenweck]

That's not a bad idea. I just hate the idea of naming what is essentially the same field with the same function differently

[ChristopherCounsell]

It's not valid survey123 design. It should throw a data validation error in Excel. If you successfully publish the survey form, you may encounter issues in the app or website, like what you are seeing now.

[AlfredBaldenweck]

It doesn't throw an error and successfully publishes because they belong to two or three different tables. It would follow that if it can publish, it should be good to go, or we need to do some serious tuning up of our error checking. If the true intent of the team is that you can't have two different tables with a "siteID" field in the same survey, that would be very surprising and inspire a fair bit of dismay.

The other thing is that it isn't like it's a consistent thing. It happens for me personally one out of like, every 15 surveys. It happened to my user more but I think that part of it is she was switching between saved drafts. Another wrinkle is that she had preloaded the surveys the night before and I had pushed an update that didn't change the schema but did change some form behaviour. I myself have not run into that because I only do one survey at a time and never pre-load them. 

[ChristopherCounsell]

The cell highlighted in red is the error/warning. Excel based validation for question types and field names.

It used to be explicitly stated in the documentation that the name column had to be unique across all tables as an XLSForm limitation. It looks like they've adjusted it to say it's unique across layers, so maybe it's now officially OK, but users till report a lot of issues when you do it this way. It's probably not the cause of the crash you are seeing but I can't recommend it.