nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Survey Populating Related Table with GlobalID

jfischer91

I have a survey where I'm using a Repeat to edit data in a related table in addition to a point feature service. I've created the relationship class using GlobalID on the point layer and parentGlobalID (a GUID field) on the related table. Everything is working except that when I submit a survey, there is an extra, totally new, GlobalID value that gets populated in a field that should be a text field (called "Project Number"), in addition to the correct parentGlobalID that references the main point, and the related table record's own GlobalID. The submission_URL points to the main feature service, not the related table.

Why is this happening?

Relationship Class (created in Pro, published to AGOL)

Survey123 form

Results in related table:

Encontre mais publicações marcadas com

Accepted answers

All comments

dougbrowning

I see a few issues.

First see those green boxes on the field name cells. Those are errors and you cannot ignore them. Those 3 are reserved words and going to cause you all kinds of issues. You need to change them.

Next I think your case if wrong on parentglobalid - my forms have all lower. Not 100% that matters but it could. Also usually its globalid all lower also.

Do you have multiple relates? I do that find but I think the latest connect may have had a bug on that. I have not seen it fill in both like that before though.

jfischer91

Thanks for the heads up on that Doug! I changed all the field names, including the parentglobalid, but the behavior is the same. The GlobalID field I just added through Pro, so the the default name has it capitalized.

I have a point layer, a table related to that, and then a second table related to the first table. The second relate is based on different key fields, not on globalid.

DavidSolari

I don't see any obvious errors (besides what Doug brought up). My advice is to copy the workbook to a new survey, publish that as a hosted service, then download the service as a geodatabase so you can compare the schemas. Other than the case of the OID and GID fields* any differences you see could be a point of failure. Worst case you blow out the old data, copy the schema you downloaded into your EGDB and republish from there, that should sort things out.

* Hosted layers name the fields objectid and globalid, but layers created via Pro include uppercase characters in the field names. This is the one exception to the lowercase field rule so don't worry about them.

Neal_t_k

What type of field is "Project Number" in your feature service? It appears to be GUID also.

What are you expecting to see in Project Number and how is it being populated?

dougbrowning

Hmm i do that and it is ok but I did here about a bug breaking this in the latest connect. @ZacharySutherby

jfischer91

Thanks all for the suggestions. After a lot of testing, I've arrived at the conclusion that this behavior is a result of having relationship classes not based on globalid/parentglobalid.

I tested the following:

-Created brand new survey using original survey's template, and published to new feature service > Successfully edited features with correct attributes; no errors. (Thanks to @DavidSolari for that idea!) I also investigated the schemas and relationship classes. The relationship type was "Composite" where mine was "Simple", and I tested both of those, which didn't seem to make a difference.

-Renamed "parentGobalID" to "parentglobalid" in first related table > Didn't seem to change any behavior by itself

-Removed second related table from original layer (the one that wasn't working) and re-published > That removed the erroneous behavior and everything worked.

-Kept the second related table but removed the "parentglobalid" attribute, and left the relationship class using Project_Number attribute > this caused the same problems (I thought it may just have been having the "parentglobalid" field present, but I guess not)

Even though it worked when I created a new survey from scratch, including a point layer with a related table and another table related to that one, both using globalid/parentglobalid for the relationship, that format won't actually work with my data. My data is structured so that the point layer represents a feature, the first related table is a work item performed on that feature, and the second related table is a list of all projects that all work items were done under. So, Point A could have 2 work items -- Inventory, Repair -- performed under 2 different projects, and Point B could have 2 work items also -- Inventory, Replace, but the Inventory item could also have been done under the same project as Point A. So 2 features in the first related table point to the same feature in the second related table. This works well for things like pop-ups, where I can show relationships between features, different work item types, and projects (I'm using Arcade to show a list in the pop-up of all projects a feature has had work done under), but it means that I can't create a one-to-many relationship between the first and second related tables. Hopefully the illustration below helps.

Point A --> Inventory --> Project 1

--> Repair --> Project 2

Point B --> Inventory --> Project 1

--> Replace --> Project 3

I was hoping to be able to make this survey so it only edits the point layer and the first related table, and maybe settle for making a different survey altogether for the second related table, but currently, even having the relationship between the first and second is causing it to break, so that's currently not feasible.

@DougBrowning, you mentioned that you've done this where you've had multiple related tables using different key fields, and it's worked in the past? If that's the case, then this may just be a bug in the latest version.

jfischer91

Confirmed that Project Number is a string. It's a field that captures the project identifier using an office numbering system that we created. Just a string like "SD-01-001".

dougbrowning

Yes our entire workflow is based on this the last 7 years so a bit concerned. I have 15 of my own relates actually (15 123 forms that relate to the same parent and works super slick). Plus all the built in 123 ones on top of that. My workflow for this is an old post here but it still works when I last published back in March. https://community.esri.com/t5/arcgis-survey123-questions/mapping-with-survey123-within-a-polygon-or-admin/td-p/836112

As I mentioned others seem to see this in the latest Connect. I think Zack said beta has a fix. Sorry I did not add this post to my first response, been a crazy day. Check this post and see if it helps at all https://community.esri.com/t5/arcgis-survey123-questions/survey123-connect-3-22-49-returning-error-quot/m-p/1626975#M63114

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.