I have trouble setting up the relationship tables for nested repeat

[YukoYokozawa]

I'm testing nested repeat using feature service I created in a geodatabase. I made three layers of repeat, and the last repeat will upload images with some notes. It's Survey-Site-Grid-Image structure. I created three related tables (site, grid and image tables) and I enable attachment to only the image table. The "Enable Attachment" created one more table and relationship class. I also created the relationship class for each table (except the last attachment table because the relationship was already created.) When I published the dataset, I added the feature layer, site table, grid table, image table, and the attachment table into the map, then published them.

I created a form from the dataset using Survey123 connect, and edit the XLS. I tried not to touch too much, so I edited only the labels and added "query=1=1 allowUpdates=True" to the bind::saveincomplete field for the begin repeat rows. Then published the form. It published successfully.

I downloaded the form into my field app (Windows version installed into my PC), and filled the survey, then submit. The problem is the submit never complete. The submission got stack with this message below. The table name is the image table in the dataset. I had no problem publishing the form, so I'm guessing I made a mistake during setting up the related tables especially for the image table. Or I shouldn't include the attachment table to the dataset?

Thanks!

[RogerFarmer1 · Accepted solution]

Hi Yuko Yokozawa‌

We had the same issue, and fixed it by not including the attachment table in the map.

Regards,

Roger.

[DougBrowning]

Yep you now cannot have the attach table in the map when you publish the service.  It just figures it out somehow.  Used to be able to.

[YukoYokozawa]

I removed the table from the map and re-published it. Re-created the form and published. Now it stacks here...

It looks better than before (it's sending data) but it's been 30 min, and still not completed. I attached 5 or 6 photos but they are all 10 to 30 KB, I think the total would be less than 100 KB (not MB!). I can't tell if I should wait for more...

[YukoYokozawa]

Okay, I checked all the features in the geodatabase and found the data I sent. I actually used the iOS field app to try again, and it stacked at the same message. Both data from Windows and iOS apps are in the feature layer and tables. I'm happy the data showed up in the tables, but I don't know what to do with this not stopping message. In the iOS app, I forced to close the app and re-open it, then I found the survey is in the outbox. So I tried to send it again, and the same thing happened, and there are the second set of the data in the geodatabase. This is not good...

Anyway, I forgot to say thanks to you both. At least the data gets into the database...

[RogerFarmer1]

Yes, I have had this issue too;

1. the mobile app paused on sending a collected survey (not an existing record)
2. stuck on green loop (or perhaps I didn’t wait long enough?)
3. I used the back button to get out of the loop
4. The record ended up in SDE (I checked with Arc Pro)
5. I went back to the app survey and the record was still in the Outbox
6. I sent again
7. Now there are two identical records (except for GlobalID and ObjectID) in SDE

This was 22 February 2019, so was Android v 3.2 on Samsung Galaxy Tab S4 SM-T835

[RogerFarmer1]

I would like to add in this part of the thread that the duplicate record appearing because of backing out of a loop could be a symptom of another issue. At that point, the relationships had already been built for all tables, etc. and this happened once only for only one of 35 similar standalone tables in the feature service.

I think this should be raised as a separate issue.

[YukoYokozawa]

Yes, exactly the same! Were you able to fix the issue?

[RogerFarmer1]

No, I think it dropped off the radar at the time because the survey was:

1. not pulling data from a csv file and using it in the instance name, and
2. the survey for a standalone table not showing in the Data section/tab of the Survey; instead it points to the feature layer in the map.

It was a situation where there were 35 individual surveys pointing to 35 individual standalone tables in a single feature service referencing 35 individual SDE tables.

I don't think I can help much from here, but it's good to know it's not happening to just me.

Regards,

Roger.

[YukoYokozawa]

I see. Thank you for answering my question! It helped me a lot.

I just found the question and answer for the sending data looping. Here is the answer for it:

"Setting the forward label and the backward labels of the geodatabase relationship class to an identical string value that is not <blank>/null resolved the problem."

I don't really understand what exactly do to fix the problem, but I'll test with my data and post the result here.