Can Views Cause Error 400: Unable to Add Feature Service Layer Definition?

[PhilipQueen]

Hello,

My team has created a large Survey123 form which I am the owner/publisher of. We have created various view layers associated with the data from the form, and are currently in the processing of making an Operations Dashboard for the data. We would like to add 5 calculations to the feature service to help our reporting in the dashboard.

The issue is I cannot publish the updated survey with the new fields. I get the usual warning about adding fields, but then the "Error 400: Unable to add feature service layer definition" when I hit "Publish Survey." I have attached screenshots of the warning and the error. I am able to publish the same form as a new survey, so I know I don't have duplicate or improper field names. The issue is republishing the survey would mean redoing a lot of work creating the views and dashboard.

Another user who had this issue last month said deleting the view layers associated with the data fixed this publishing error. Is it true that the views we have created could be "locking" the feature service schema from changing? If so, is there a workaround? And if not, what else could be the issue here?

Thanks for your help,

Philip

[PhilipQueen]

After doing more digging, it looks like the service definition has the properties "sourceSchemaChangesAllowed" : false and "hasViews": true. I'm not sure if those are related, but would it cause issues to set "sourceSchemaChangesAllowed" : true? There is no way to click it on or off, so it would be something of a 'crack'

[PhilipQueen]

Update - it looks like "sourceSchemaChangesAllowed" dictates whether the view layer is able to change the schema, not whether the view layer locks the schema from being changed by Survey123 Connect. 

Still totally at a loss here. Deleting all views layers and maps referencing the service allowed me to republish with new fields, but it's not something we want to do again. I would really appreciate a workaround here.

[JamesTedrick · Accepted solution]

Hi Philip, 

Yes at this time Connect cannot alter a form with a view as teh editing endpoint.  In this situation, you can add the fields to the feature service manually, check to make sure they've been added to the view definition and then update the form.

[PhilipQueen]

Thank you James! It is good to know that is a setting, and that there is a viable workaround.

[PhilipQueen]

James Tedrick‌ I tried this method (adding fields through the data tab before publishing) on a copy of my survey that had dummy data, views, and an Ops Dashboard and it worked great. But when I went to do it on my real survey, the "Add Field" button was gone from both the table and field views of the Data tab. I also tried adding a field through Pro, and it returned an error (error 000852: Cannot add field <value> to <value> (http://pro.arcgis.com/en/pro-app/tool-reference/tool-errors-and-warnings/001001-010000/tool-errors-a...)). Do you have any idea what could be causing this?

[JamesTedrick]

Hi Philip,

Are one of the views created using multiple layers?  It appears that once a multiple layer view is created, neither of the participating layers can have their schema updated.  In particular, if you visit the REST endpoint/service URL of the survey layer, you should see a property called 'Source Schema Changes Allowed'm which is probably set to false in your case.

[PhilipQueen]

James,

Thanks for following up on this, it's good to know that multiple layer views cause this setting.

I was able to correctly diagnose what went wrong in our case. We had created our views with a script that set "Source Schema Changes Allowed" to false and locked our schema. This property for the hosted feature layer is calculated from all of the view layers, so if one view layer has it set to false you can't change your schema. This explained why we initially couldn't change the property in our hosted feature later through REST. But we also couldn't change the property to true in any of the view layers through REST, until Khaled Hassen told us that 'hasStaticData' has to be set to the opposite boolean value as "Source Schema Changes Allowed" - so to change the latter to true you have to set the former to false at the same time for the update to take. So we were able to make all of the changes and then add the fields we needed.

Hopefully typing this all out here helps someone solve this issue a little quicker than it took our team. Thanks again James.