Survey publishing error: supportsApplyEditsWithGlobalIds

[SamanthaNakata1]

I am currently trying to publish a survey with a custom SDE-based feature service.  The service includes the point feature layer with a related table (relationship via a GUID; for repeats);the related table has attachments enabled.  

The submission url in the form has been edited to that of the feature service, so something like:

http://utility.arcgis.com/usrsvcs/servers/.../rest/services/[FolderName]/[ServiceName]/FeatureServer

When attempting to publish the survey I receive the error:

The custom feature service submission url is not compatible with this survey (The feature service does not meet the requirements for a survey with repeats - supportsApplyEditsWithGlobalIds)

I have not been able to find much about this particular error online--anyone who overcame a similar issue? The error message seems to indicate an issue with the relationship to the related table? But I was able to publish a survey with this database structure previously with no problems.  I have also tried to publish the survey with a GLOBAL ID-based relationship, but this also did not work.

Thanks all.

[MarkBennett]

Hi John,

The fgbd contains many data sets and attachments, therefor, it is very big in size (1.4 GB and 700MB compressed). I am going to strip it down and then ask you for ftp link.

Both feature classes in FGDB contains attachments and I noticed that the ATTCH tables and featurclass is related using OID instead of GlobalID in FGDB. I am not for if this could be a problem to set the “supportsApplyEditsWithGlobalIds” to true?!

Ming

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

[MarkBennett]

Hi John,

 As I suspected, the attachment table related via OID is cause! Once I change the PK/FK to GlobalID and re-published service with sync enabled, the supportsApplyEditsWithGlobalIds became true! 

Because this is a legacy database that was developed and accumulated over 10 years, many of the relationshipclass were created using oid for PK/FK. It will be nice to have tool to converte to GlobalID:). 

Ming

[MarkBennett]

Ha, there is a tool to convert the relationship class from oid to gid

Ming

[MarkBennett]

Hi John,

As you can see on the GeoNet posts, I have resolved the set “supportApplyEditsWithGlobalIds” to true issue. However, I get into a new issue with this survey – the completed survey cannot be send to Feature service. After clicking on the send button, the screen stuck on the “Getting service information” message with, and, regardless if I send survey from hydrant flush or valve exercise, it always stuck on the Getting service information for “Valve_ExerciseRecords table. Can I share my survey and feature service with you m and let you take a look of this issue?

Thanks,

Ming

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

[JohnathanHasthorpe]

Hi Ming - yes please provide your survey/service and I'll take a look. Make sure you include the survey .xls file as well. Thanks

[MarkBennett]

Hi John,

I found the cause and resolved issue. Here was what was going on:

I converted the relationship class from oid-based to gid-based for the ATTACH tables, then, republished the feature service. However, for some reason, the layer # was shifted. The two layers and two tables should be layer 0, 1, 2, and 3 in the feature service, but became 1, 2, ,3 and 4. I believe that survey would start searching for request layer or table from #0 when it was submitted. I guess that might be why the process is stuck there. But I do not know why the # would shift.

Anyway, I deleted the old service and created it again. It works now.

Thanks a lot!

Ming

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

[JohnathanHasthorpe]

Hi Dan 

It looks like you have fixed layer 0 in the feature service. But the form is actually targetting layer 1 (check the form_id in the settings tab). If you fix layer 1 (i.e. enable applyEditsWithGlobalIDs) you will be able to submit successfully.

Thanks

John

[DanielMcIlroy]

Thanks for that John, although I’m not 100% sure how to change this. Layer 1 is a table and there aren’t any obvious options to do make this kind of change.

The hosted feature layer has had the change made but it hasn’t been applied through to the table, and therefore the whole "Hosted Feature Layer" is considered False.

As you can see below, I've tried all the options to make this change but nothing seems to make it's way through to the table.

[JohnathanHasthorpe · Accepted solution]

Please see: https://community.esri.com/groups/survey123/blog/2018/07/17/how-to-turn-supportsapplyeditswithgloabl... for steps on how to do this.