Update subnetwork - "expected field was not found"

[EdwardBlair]

Created a subnetwork controller for a pipeline distribution system (a custody transfer meter), tracked down and resolved validation errors and am trying to update the subnetwork.   What I get is below.  The server log shows the same, somewhat cryptic error.  Is there a way to find what specific field or fields the Update Subnetwork GP tool was looking for that it can't seem to find?  Not sure why there is a field it can't find in the first place as I'm using the UPDM 2018 asset package as my starting place.

Any pointers would be much appreciated.

Thx,

Ed

[PaulLeBlanc1]

Can you run a Subnetwork Trace on the subnetwork you are trying to update?

[EdwardBlair]

Paul -

Thanks for the reply.  Yes,actually it seems I can run a subnetwork trace.

Ed

[EdwardBlair]

For what it's worth, I re-ordered fields in the PipelineLine and PipelineDevice classes before publishing the feature service.   For example, moved the LIFECYCLESTATUS field closer to the top so its easier to see.  Would this make a difference?

Thx,

Ed

[PaulLeBlanc1]

Can you republish with everything as default (so add the UN and layers to new map and publish that)? If a field is not visible, that could be causing your issue.

[EdwardBlair]

I'll try.. but I didn't change field visibility, just the field order.

[EdwardBlair]

So... for some reason I really don't understand when I applied my asset package the subnetwork fields (systemsubnetname, pressuresubnetname and isolationsubnetname) did not get added to all of my Pipeline classes.   

What I did to resolve the issue was to back out all the way - removing feature services and deleting the feature dataset, then staging a new utility network and applying the same asset package.  Then loaded data, configured subnetwork controllers and resolved *all* validation errors.  At that point I got "Update Subnetwork" to work.

A couple points:

1.  The first (failed) time through I know I reordered fields in the Pipeline classes to make things more readable -- for example, moving LIFECYCLESTATUS to the top.   It *may* have been the case that I changed the visibility of a critical field as well -- I don't think I did, but can't say it wasn't possible.  The second time (that worked) I made no changes to Pipeline class fields at all.

2.  Rather than having to resolve *all* validation errors it may have been the case that I could have set some trace barriers to isolate the "good" part of the network from the "bad" and thus followed a piecemeal approach to validation.

3.  It would still be good when receiving an error message that says "Expected field could not be found" that the software would also tell you *which* field it was looking for.

Got some pointers from Esri tech support along the way - for which I say "thank you"!

Ed