Schema changes to registered dataset not reflected in Portal

[JordanKeller]

-Working with ArcGIS Enterprise 10.8. Server federated with Portal

I've published a feature class to Portal referencing registered data from our SQL Server database. The feature layer in Portal behaves as expected and edits made are showing in the source dataset in SQL Server.... all good.

My problem is that I want to make a schema change to this feature class (add a field), but I'm having trouble getting this change to be honored when I republish to Portal. 

What I've tried:

- I stop the map service in ArcGIS Server Manager to remove the lock on the feature class

- I added the field to the feature class. 

- I first tried simply restarting the map service, but I couldn't see my new field in Portal. 

- I then assumed that republishing was required for me to see my new field in Portal, so I overwrote the layer in Portal, but I still can not see the new field.

- I thought this was strange, so I published a new feature layer to Portal from the same data source, and even this feature layer did not show my new field!! 

What is the expected workflow to get a schema change made to a feature class in SQL server (add/remove field, add domain value, etc) to be reflected in the map service in Portal?

[jcarlson]

We're on postgres, but the workflow ought to be the same:

1. Stop service
2. Make necessary changes to underlying DB via Pro (Right-click layer → Design → Fields)
3. Republish

Stopping and starting, as you assumed, won't be enough to catch a schema change, as the fields need to be written into the service definition.

When you published a new layer, did you also give it a new name? I doubt that a browser cache issue would cause this, but it's worth checking.

Is your data versioned, or do you use views at all?

[JordanKeller]

This dataset is not versioned and not part of a view.
I've followed the steps you have mentioned, unfortunately no luck. Almost as if the service definition is not being updated to reflect what's in the database.
When I tried to publish the new layer, I gave it a completely new name.

[jcarlson]

That's very curious... The fact that the new-name version of this would also lack the new field points to this perhaps being a DB-level issue. Do you have other services or a throwaway layer you can test this with?

Also, can you confirm whether or not the field is present in the service JSON at web-adaptor/rest/services/path-to-layer/FeatureServer?f=pjson

If you're comfortable with it, try editing the service defintion directly to add the field. You can use AGO Assistant to do it. I've had other layers (hosted, not server-based) where I had to add a new field via the JSON directly, and it worked.

[JordanKeller]

This was my throwaway layer haha...
I do not see the field listed in the service JSON.
Thanks for troubleshooting with me. I may have to open up a ticket, as I'm at the limits of my knowledge on the subject.

[jcarlson]

If support is able to help you, come back here and post it as a solution for the next person!

[CraigRussell]

Hi Jordan

I've done a few tests with Pro 2.7.1 and ArcGIS Enterprise 10.8.1, and while I've seen inconsistencies in the way that the addition of new fields manifests in Server/Portal, in general it has worked with just a service restart (i.e. not republishing the service).

A few things to check:

1) Is the new field being flagged as visible in the Fields view from the map that you're publishing?

If not, then it won't appear in the service definition.

2) Do you see the new field listed in the rest endpoint for the map/feature service?

3) Has the field been added but is just not visible by default in Portal (e.g. from the Data tab on the Portal item page)?

Something that I've seen with a fair bit of consistency is new fields not being made visible by default.

Cheers

Craig

[JordanKeller · Accepted solution]

Just wanted to give an update.
I came back in this morning and checked my service to find the new field now shows up!
We do have a nightly script running on our server that stops and starts all map services, but I was stopping and starting services when I was testing the addition of the new field yesterday....
I wonder what tripped the change this time? Or maybe there was some lock on the feature class somewhere? I wouldn't think it would be a performance lag from our remote server, but I'm not sure...
Anyway, thank you all for the help. It seems resolved for now, but I'll post any updates if I can pin down any other reason why it wasn't working.