ParentRowID not populated in Repeats Related features/objects

[JeffPuuri]

I also posted this question over in github in case this is an issue.  I have built a form in Survey123 Connect containing a Repeats section.  When I publish my form, a feature service is created with a (feature) layer and a table as expected.  When I examine either the layer or table in the REST endpoint, both show the relationship class between the two, also as expected.  When I complete a form using the Survey123 app and submit, I get a single feature corresponding to the location where I filled the form, and I also see the same number of records in the table corresponding to the number of repeat sections that were completed, again as expected.  However, the relationship class between the features and table records cannot be traversed, or viceversa.  For example, I can add the feature service to a web map, click on the feature to invoke the popup, and when I click on the link to view related records (meaning the popup recognizes the presence of a relationship class), the response is 'No related records'.  What I have noticed is that the field ParentRowID in the related table, presumably the foreign key, is always empty.  Back over in the corresponding feature, the RowID is always filled in with a value.  Based on what I have described, is this expected behavior, operator error, or possibly a software issue?  Thanks for any insight that anyone can provide.

[IsmaelChivite]

Hi Jeff,

thanks for your comment. We are looking into this issue and will try to fix soon.  Thanks a lot for bringing this up.

Ismael

[GaryBowles1]

We are having the same issue. None of the photos that were in a repeat are visible in Portal or in the __ATTACH tables in the fgdb.

--gary

[GaryBowles1]

I just tested another app that contains photos within a repeat and photos taken outside of a repeat. The photos within the repeat were not in the fgdb when downloaded and not viewable in Portal. The photos taken outside of the repeat were viewable in Portal and downloaded properly in the fgdb.

[JeffPuuri]

Gary, have you tried adding a geopoint field alongside the image field in your repeats block?  Such that now your repeats section will have both an image field and a geopoint field, along with the other capture fields.  That will force your repeats records to be stored inside of a related feature class instead of a related table.  I was testing the same configurations that you are describing and once I added a geopoint field to the repeats block containing an image field, the related feature has the image attachment.  Now granted, the relationship between the parent feature from outside the repeats block to all the children corresponding to each repeat is not established due to the ParentRowID not being populated as I originally reported, and Ismael confirmed.  What I think is happening on this related image issue, and it should probably be raised as a separate issue, is that attachments in related tables are not being created, although attachments in related feature classes are being created apparently just fine.  Let me know if you get a chance to try the geopoint field and what results.  I'd be very curious to hear how someone else's testing on this topic turns out.

[GaryBowles1]

I have not tried that but I will give it a go and let you know what happens.

Thanks,

--gary

Gary H. Bowles

GIS Database Administrator II | Seneca Resources

Office : 412-548-2544 | Cell Phone: 412-334-5273

[IsmaelChivite]

A follow up on this issue: We have identified the issue and have a fix which is undergoing certification testing.  This issue is critical and will issue a special path for the apps as soon as we can.

[IsmaelChivite · Accepted solution]

Fix available in the stores now

1.2.89: Critical Update to the Survey123 mobile app

[JeffPuuri]

Thanks for this fix.  I have tested it out on the Android side and it is working as expected now creating navigable related records from repeats blocks.  I will test out the Apple version as soon as it shows up in the App Store.

[IsmaelChivite]

Thanks for checking.

The fix on iOS is also available now: 1.2.89