Select to view content in your preferred language

Unsupported relationship type when publishing

4016
8
Jump to solution
04-07-2021 11:45 AM
KirkJones
Emerging Contributor

I am trying to create a survey in connect version 3.11.123  using an existing feature layer.  There are two related tables and both the primary and foreign keys are the globalid.  When I go to publish I get an error stating "survey123 unsupported relationship type esriFieldTypeGlobalID in key field globalid for table globalid".  I haven't really found anything in my searching for solutions.

Capture.PNG

1 Solution

Accepted Solutions
DougBrowning
MVP Esteemed Contributor

The related table calls the field parentglobalid.  You can have other relationships but this one has to be there i think.

Hope that helps

View solution in original post

0 Kudos
8 Replies
DougBrowning
MVP Esteemed Contributor

The related table calls the field parentglobalid.  You can have other relationships but this one has to be there i think.

Hope that helps

0 Kudos
KirkJones
Emerging Contributor

I apologize for my lack of understanding.  So does that mean I need to add the parentglobalid field to my table?

0 Kudos
DougBrowning
MVP Esteemed Contributor

yes add the field parentglobalid  string 255 to the child table.

0 Kudos
KirkJones
Emerging Contributor

Thank you

ShariForbes
Regular Contributor

This solution worked; however, the "parentglobalid" has to be a GUID field, not a text field, otherwise you cannot make a relationship class with two different types of fields. 

0 Kudos
IanMackenzie
Emerging Contributor

I suspect the issue may be using the same name for primary and foreign key (primary key in/of the parent table and foreign key of the parent in the child table).  These names need to be different, e.g. "GlobalID" as the primary key of /in the parent table, "parentglobalid" as the foreign key of the parent table in the child table (see example screenshot below).  I didn't try changing the names from what was previously suggested so its also possible this is just an ESRI naming convention that needs to be adhered to.   I set both keys as type GUID.

 

Capture3.jpg

0 Kudos
DougBrowning
MVP Esteemed Contributor

They do not need to be different - I use the same field name on both sides of the relationship class all the time.

It is 123 that has to have those set field names since it is coded in.

0 Kudos
Slamon
by
Occasional Contributor

This issue persists in v3.13.  If I build a workbench from scratch that includes repeats, the relationship class that is created will use GlobalID from both tables.  So why doesn't this work when using a feature service?

the attachment shows the participating tables and how they are related to each other at this stage.

0 Kudos