Latest Contributions by RobertKrisher

That's something you'd need to reach out to support on. The original issue that was logged was actually fixed last year, but this separate issue was separate out because there is also a branch versioning specific aspect to this. ... View more

Can you replicate this behavior by running the same trace inside ArcGIS Pro? Does this only happen when the fuse has terminals? ... View more

Take a look at the spatial index on the dirty areas table, I have seen quite a few instances where the spatial index needs to be recalculated in order to improve performance. Pruning rows can help mitigate a bad spatial index or an undersized environment. ... View more

@PeterKing It breaks my heart to see that someone went through all the trouble to do the hop over the transmission main, only to have a fitting created to connect them. But then again, it may just be payback for not having done the hop on the third line (which somehow was spared from getting a tap). ... View more

@GeorgeJonesRIGOV if you disable schema locking on your service, you need to make sure you manually restart that service after you make any schema changes (utility networks, fields, anything). Otherwise, the service itself may not reflect the changes you've made which can result in some unpredictable behavior. ... View more

Is this in an ArcGIS Enterprise environment? If so, services place schema locks on the dataset so you'll need to turn off the corresponding services (or disable schema locking and remember to restart the services after making changes). More info: Utility network management tasks—ArcGIS Pro | Documentation ... View more

@JordanScupien this is a completely different issue and should really be its own thread. If my advice here doesn't solve your problem, please start a separate discussion. I'm not sure how you got your DATA from one environment to the other, but it sounds like the lines aren't connected to the correct terminals on your subnetwork controllers. The only way you will not get ANY pressure line features in your subnetwork is if there aren't any lines connected to the terminal of your subnetwork controller. If you only get the first line, then there is a problem with your condition barriers (on either your controller or the device). ... View more

The shortest path trace is the way to go. But it has two limitations, similar to the connected trace, because it doesn't rely on subnetworks: You need to manually add all your condition barriers to prevent them from passing through closed valves These traces will ignore the directionality of terminals (without a subnetwork controller to define sources/sinks, there is no upstream/downstream) You can find an example of this in the Perform quality assurance on subnetworks tutorial on the Learn site. ... View more

The bug only occurs on update subnetwork, so I'm not sure it applies to isolation traces. Can you explain? ... View more

If you remove the related records parameter from your script does it fix the publishing error? Did you try changing the parameter order? ... View more

If you look at the features in the service, are you able to see the coded value descriptions? It is possible to publish a feature service in a way that it does not include information about the domain. Either way, that sounds like a bug with FME. ... View more

I'm glad you were able to figure it out! The key to understanding what was going on was the Status attribute. Object Error means there's an error with an object associated with the feature (or with one of the associations on the object). ... View more

If you haven't already, log a case. With the number of rows you have in the dirty areas table it seems unusual that it would take that long to draw (unless you're drawing at full extent). In cases where I've seen this performance in the past (zoomed into 1:10k and getting a 3 minute draw time) it has been because the spatial index on the dirty areas layer had an unreasonable number. ... View more