Select to view content in your preferred language

Publishing Survey using fields that are Non Editable

1442
6
Jump to solution
08-18-2023 11:52 AM
LorindaGilbert
Frequent Contributor

Hi All,

I've got a S123 Survey that is set up to pull existing data that has Attribute Rules associated with it in the SDE.  I've already set up the Pro Project and the Web App for editing in that format.  However, the client prefers to have a form to fill in without using a map (it's the way it's been done since the client has been here).  So, my AR has calculations that are WAY too complex for the S123 form, and the result has to be set to non-editable as the calcs are set by council and the state.

Using Connect 3.17 and have the form pulling the data as it should.  Tried to publish and it gives an error about custom feature service submission url is not compatible and that a field is not editable.  I' attempting to publish to our Enterprise Portal at 10.9.1. 

LorindaGilbert_0-1692384251721.png

If it has an issue with one field not being editable then it seems to me that it would also have an issue with the fields for editor tracking - which will be turned on - that are non-editable as well.

Anyone have any suggestions?  And not make the field editable, can't do that.

Thanks,

Lorinda

0 Kudos
1 Solution

Accepted Solutions
RobertAnderson3
MVP Regular Contributor

In the Survey123 XLS you could try adding 'null' to the bind::esri::type field, it allows you to have the field shown in your form, but it doesn't submit it to the layer (or create the field if you don't need it).

I just did this for objectID because I want it to be able to be seen in my instance_name in the Inbox.

View solution in original post

6 Replies
RobertAnderson3
MVP Regular Contributor

In the Survey123 XLS you could try adding 'null' to the bind::esri::type field, it allows you to have the field shown in your form, but it doesn't submit it to the layer (or create the field if you don't need it).

I just did this for objectID because I want it to be able to be seen in my instance_name in the Inbox.

LorindaGilbert
Frequent Contributor

Hi Robert,

That worked great for several of the fields in my survey that I need them in there to gather data, such as x, y and setting my urls for the layers.  Thanks a bunch for that tip!  Now it has another issue that I will reply to my original post with.

LorindaGilbert
Frequent Contributor

Actually the other issue was solved by putting the fieldtype as null as well.  Now to see if the form works as published for editing existing data and for add new!

Amarz
by
Frequent Contributor

Hey @RobertAnderson3 I am experiencing the similar issue, where when I change the bind::esri:type field to 'null' it will remove the error but now when I publish it will not complete and just spin and spin. Any ideas?

0 Kudos
RobertAnderson3
MVP Regular Contributor

Was the field you're changing to null created by the survey publish process or already existing? Had the survey been published and working before this change?

Were there any other changes to the form that you made at the same time? What version of Survey123 Connect are you using and what was the survey originally published in?

And are you signed in as the same user who owns the form? (Just trying to cover all bases

0 Kudos
Amarz
by
Frequent Contributor

Thanks for getting back, sorry for the delay I am not getting notifications for some reason. 

But I believe I figured it out, it either had to do with the feature class not being set to allow nulls, or it had to do with the data types. I got it to work by forcing all my fields to be strings.

0 Kudos