Results View Contains Additional Tables compared to Main Feature Layer

[RobertAnderson3]

I have been troubleshooting an issue with the Survey123 website not loading a selected entry properly in the panel that pops up to show the details in the form view, it just spins endlessly. Through this we have noticed that the surveys that seem to have the issue all have an additional table in the results view. 

Main Layer:

Results View:

Has anyone else encountered this? Any ideas what causes this?

I'm trying to figure out how this would have happened and I can't come up with anything unusual that I would have done, I simply share the results from the Collaborate tab on the Survey123 website, and it creates the results view automatically. 

This explains why I had issues updating the view from the Settings tab in the item details for the view as well (the questions were all mismatched for the respective tables) though I feel that Survey123 publishing should do this automatically too.

[abureaux]

How did I miss this question?Just found it via your Idea.

I checked my View layers, and I don't see any additional layers/tables (Enterprise 11.3).

However, I create all my view layers from the Portal rather than the S123 Website. Not sure that would have any affect though. Maybe there was a hiccup in the communication between servers resulting in a duplicate layer?

[RobertAnderson3]

No idea, there were a few things I posted in the last little bit I was surprised not to get a notification from you on haha

All of my surveys are hosted in AGOL not Enterprise so it might make a difference, all are published via Connect, but the views would be created automatically when picking the sharing settings on the S123 website. I have no idea how it happened, or when honestly, which makes it harder to track down the exact cause. A hiccup is definitely possible, they're numbered differently though so it should have been able to tell what was there? 

[abureaux]

Now I feel bad! I will have to scroll through the list again lol.

The numbering is basically an OID starting at 0 and is generated when an item is created. Given that, I would guess that the duplicate layer was created when the view was originally created. Otherwise, I'm not sure how they would be 0 and 1, respectively. If it happened later, I'd expect to see the original as 0 and the new one as 4.

We actually had an odd thing happen late last week with those ids. A layer was (I assume) republished by someone, and the layer Id changed from 0 to 1, breaking our Web Apps. Once I realized what happened, I had to jump through some hoops to restore widget functionality. Not quite the same issue you are seeing though.

Maybe just recreate the View an monitor for now?

[RobertAnderson3]

Haha no worries! I figured maybe you were on vacation or something lol.

That's a good point, it is odd that it is 0 and 1 like that, though I wonder if it's because it's the primary feature layer and then the rest are related tables, it would always be put as the higher number?

When I try the update view, it shows me the 4 expected tables, but the fields are like:

Mowing Work Orders (0) --> Mowing Work Orders (0)
assetRepeat (1) --> Mowing Work Orders (1)
employee_repeat (2) --> assetRepeat (2)
vehicle_repeat (3) --> employee_repeat (3)

So the fields don't line up, I have no idea what it will do if I try to proceed with updating the view, I'm worried to try when it's live data lol.

I figure it was a publishing error somewhere along the line, but in the Survey123 environment, I haven't seen anyone else complain about it though so. 

I am planning on deleting and resharing the results views, I have done that on one of the surveys I have already and that's how I found it as a solution, I just wanted to try and find the cause as well.

[abureaux]

The good things about View layers is they don't actually contain any data. So even if it's live data, creating a new View in the Portal and have it exist adjacent to the current View shouldn't negatively affect anything. Then, when you confirm it's working properly, you can essentially swap layer IDs in apps.

I did something similar to this recently when I needed to make a big app update. Worked a lot smother than I was expecting!

I agree though. I hate not knowing the cause of something, even if the issue is "resolved".

[RobertAnderson3]

I don't know that it's quite as straightforward for AGOL Survey123 layers, I think I need to delete the existing before I create the new one because I don't have control over what the Survey123 website links like you would with Enterprise apps.

I have used this strategy in other cases though! I still feel like I have lots to learn about best practices around views, but they are certainly handy.

Yeah I hate it too, cause what if it happens again? This is why I wanted to bring it up to make sure Esri sees it and others can find the issue too if it happens to them.

[RobertAnderson3]

I just tried this delete and re-create method and somehow the new version of the view created simply by sharing the results in the Survey123 website also has the additional table... weird.

[abureaux]

Hmm. So maybe not a mistake then? I'm at a loss.

If you go to the "Schema" tab in Connect, I assume you see what you'd expect to see?

[RobertAnderson3]

Yeah I see the expected tables, only one of the core table, and the main hosted table has the expected results as well, it's only when the results view is created that it does this.