Survey123 Error: Global id based relationship requires support for applyEdits with GlobalIds

6071
9
03-23-2017 10:16 AM
DiegoLlamas
Esri Contributor

Hello,

I am trying to migrate my survey from AGOL to be hosted in Portal/Data Store. I do the next steps to host my survey on Portal/Data Store

1. we follow these helpUse Survey123 with ArcGIS Server—Survey123 for ArcGIS | ArcGIS

2. Then after creating service on server we follow these stepsUse Survey123 with Portal for ArcGIS—Survey123 for ArcGIS | ArcGIS

And in this step we are getting this error "Global id based relationship requires support for applyEdits with GlobalIds"

Further test and research indicated that the issue is specific to relationship class which ArcGIS Online creates for configuring repeats with the data. When the data is being downloaded from ArcGIS Online. The relationship created by default is between "Primary Key : Global Id" and "Foreign key : parent Global ID"

As per the documentation:

"If using ArcGIS Server 10.3.1, repeats cannot work with related layers or tables unless the relationship uses a GUID field for the relationship in the parent layer. Although not a requirement in later versions of ArcGIS Server, best practice would be to use a GUID field for the relationship in the parent layer. "

https://doc.arcgis.com/en/survey123/desktop/create-surveys/survey123witharcgisserver.htm#ESRI_SECTIO...

I have tried different relationship classes for e.g. based on "Global id" vs "GUID , "GUID" vs "GUID".

It has never worked for me. As well as, The behaviour with data downloaded from ArcGIS Online, as per my understanding is perfectly acceptable "The Custom feature service (Submission url) is not compatible with this survey (Global id based relationship requires support for applyEdits with GlobalIds)." as the global iD are not editing enabled.

Does anyone has any idea about this? Am I doing something wrong if I want to host my survey in portal/Datastore?

Thanks for your help.

Diego Llamas

9 Replies
GaryBowles1
Occasional Contributor III

Diego,

Survey123 does not work with GlobalID, GUID relationships for related tables (repeats) with Federated Servers yet. It is in the works but is not there just yet. I believe it may be available in the next release in April?? The repeats use ParentRowID/RelatedParentRowID for the repeats.

--gary

0Kudos
DiegoLlamas
Esri Contributor

Thank you Gary for your information.

0Kudos
danbecker
Occasional Contributor III

Server 10.3.1 not federated.

I followed the above documentation to get a survey123 repeat working to no avail. I tried every combination of globalID, GUID, parent--child relationship in the feat. service relationship class to no avail.

After publishing the feat. service, I added the REST feat. service endpoint URL as an item to AGOL, saved the credentials with the item, then included that arcgis.utility....URL in the xlsform service_url field. The name of the repeat was exactly the same as the related table name in the feat. service.

Using survey123 connect, every time I tried to publish the survey to AGOL, I would get the error, "parent relationship not found from ".

If I re-publish the feat. service w/out the relationship class, then re-publish the survey w/out the repeat, everything worked great, and we are able to host the survey123 feat. service on our non-federated server. Which is ideal for us since we are running low on AGOL credits.

Another issue: I can publish a survey123 repeat to AGOL, the hosted feat. service is automatically created in AGOL and everything works as expected. HOWEVER, if you try to download the hosted feat. service as a FGDB it fails because it contains a relationship, i.e. related table. If you download as .csv everything works as expected.

Looks like a few more relationship bugs exist.

0Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Dan,

Yes, there are a few caveats with relationships. From your description, it sounds as if the *relationship* does not have the same name from the parent and child tables - currently Survey123 assumes the relationship name is the same.

There shouldn't be any issues downloading an FGDB- it supports relationships.

danbecker
Occasional Contributor III

Thanks James. The above documentation does not list the requirement for the relationship to have the same name in each direction. I just ended up publishing a hosted feature service on AGOL rather then trying to use our un-federated server.

However, I still cannot export a FGDB from the hosted feature service. I can create a replica FGDB from the parent layer serviceURL, but if I go to the hosted feature service item details page, and hit "Export/FGDB" it always errors out. I would assume the issue is with the relationship class created via the repeat in the survey123 connect markup.

I also tried to add the hosted feature service to ArcMap 10.3.1 from the "my hosted services" folder. The parent point layer displays fine, but the related child table errors when trying to open it "could not load data from the data source....". I also tried to "create a local copy for editing", and got another error "a general error when something is wrong with a field [parentglobalid]." Perhaps all these errors are related to my 10.3.1 deployment of desktop and server? Regardless, there seems to be issues with repeats and relationship classes.

I need to move the feat. services onto our own server now that I know about the relationship naming requirement. Then I could just use the data locally in our own SDE GDB; lot less hassle.

0Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Dan,

With regard to the export issue- if you haven't already, could you please file a support ticket on this? There are a few different reasons why export might fail and it would be good to see if this is one of the known cases

0Kudos
danbecker
Occasional Contributor III

I finally got a survey that uses repeats working with a non-federated 10.3.1 feature service. The trick was to create a GUID field (NOT GlobalID) in the parent point layer, then use the field as the primary key in the relationship class. The foreign key (child table) also uses a GUI field.

LeahSperduto
New Contributor III

Dan (or anyone who was able to get this to work),

Can you clarify what the other tricks were you used to get this to work? I have tried (what I think is) everything but to no success. I am seeing a lot of conflicting documentation too. What did you use for the following in addition to the GUID to GUID relationship?

同步启用的功能服务——“是”或“否”(if yes, was your data registered as versioned? - if yes, did you Register the selected objects with the option to move edits to base?)

-Archiving enabled - Yes or No

Also, was this working in an SDE environment or FGDB? I am hoping to get this from my SDE

Any help you can offer is appreciated.

Thanks,

Leah

0Kudos
danbecker
Occasional Contributor III

Sorry I can't help

我们因为ArcG迁移到本地门户IS with a federated 10.5 server, datastore, dedicated Linux PostgreSQL db server, all on separate Win/Linux VM's. Its been flawless since 1 June.

This solved the variety of syncing issues we were having, as well as little nuances like this thread.

It's really nice to fire up Survey123 Connect and publish a survey to Portal that shows up as a hosted feature service, it's super easy and best part is that it doesn't consume credits.