Latest Contributions by MelissaJarman

The help referenced above should help you get these removed and fully deleted from the subnetworks table. When you just remove the subnetwork controller using the Modify Subnetwork Controller pane, the subnetwork name is still listed in the system. Are you still seeing the subnetwork name show up in the dropdown after all controllers that used that subnetwork name are removed and export subnetwork with ack is executed?

Are you able to consistently reproduce the validate not taking away the dirty areas when the error situations are resolved? If so, I would be interested in the repro steps as you should not be forced to disable and reenable the networks topology to clear these.

The Dirty Areas are symbolized using the status field - The Status attribute field uses bitwise encoding to represent the operation that created the dirty area. For example, a deleted feature is represented by bit 1 and is displayed with a status of 2 (2^1 = 2). These values are summated if multiple operations led to the creation of the dirty area. A Status Description field is displayed in the pop-up expression to provide additional information about the operation that created the dirty area. You can review the following pages to see if they provide you with help on how to use Errors. Errors Error management

Loren - Enterprise geodatabases should be able to handle the overhead of the extra utility network, but from an administration perspective you just need to be aware of how these are named and associated. I currently have several utility networks in a single enterprise geodatabase for internal testing. It is up to you as the geodatabase administrator to decide if this is something that works for your organization. There are a lot of dependencies such as load, size, etc.

There should not be issues with creating multiple UNs in the same geodatabase. The non-spatial object tables will be created with _1 appended to the end of them. The UN system tables, domains, etc all use the OBJECTID from the GDB_ITEMS table for the utility network they pertain to as part of the naming convention. It might be a good idea to do the same for any user-defined domains that are created in the geodatabase to keep up the organization. Here are a few domains with the naming convention mentioned:

‎12-24-2020

Thanks Jimmy for your input. If you are looking to report the utility network configuration, you can also using arcpy describe. Utility Network Properties

‎12-24-2020

Sarah - Thanks for bringing this up. This is a result of the Modify Associations pane being reworked to support nonspatial objects for the utility network. We will work on getting this learn lesson updated for the updated UI of the Modify Associations pane. You simply need to use the Add Features or Load Selected buttons in the pane to set the active item.

‎12-17-2020

Not sure if this is your problem, but worth a try... Starting at ArcGIS Pro 2.7 for enterprise geodatabases, the tools to create and upgrade a utility network look at the ArcGIS Pro and ArcGIS Enterprise versions to determine what version of the UN to create or upgrade. You won't be able to upgrade to UN version 5 unless you have a federated server of 10.9 for enterprise geodatabases. Check out the section on ArcGIS compatibility https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/utility-network-dataset-administration.htm#ESRI_SECTION2_D2C5FA67C0AD46F6A893CF18F9493181

‎12-16-2020

Lindsey - It sounds like from your workflow that you are experiencing expected behavior for updating subnetworks in a named version. In a named version only those rows (network features) that are edited will be updated by default. Since the subnetwork features were not edited when you disabled/reenabled the device feature as a subnetwork controller, they are not being updated with the subnetwork name during update subnetwork. This is one of those gotchas that definitely tripped me up too. You will need to reconcile/post with default and update subnetworks in default. I would recommend performing these operations in default and then reconciling your named versions. If there is an absolute need for this to work in a named version, you could change the Edit Mode for Default Version to With eventing (new at 2.6/10.8.1). See the following topic for more information: Update subnetworks Let me know if you can try the following: 1. Make a small edit to one of the subnetwork features in the named version and verify that update subnetworks does update the subnetwork name attribute for this feature due to the edit. 2. Reconcile/post with default, run update subnetwork in default, and then reconcile again in the named version.

‎12-02-2020

It would be helpful if you could capture the ArcGIS Server logs at the time of the validate failure to see what specific error is returned. It may even be good to get your data inhouse so our development team can test against your data. I am not sure if that is a possibility, but please let the analyst you are working with know if this is possible. It does sound similiar, but without getting a closer look at the logs we won't know for sure what the cause in the validate failing. https://support.esri.com/en/bugs/nimbus/QlVHLTAwMDEzMzE4NQ==

Online Status	Offline
Date Last Visited	Tuesday

My Ideas

Latest Contributions by MelissaJarman

Re: Subnetwork Name Delete?

Re: Dirty Area Status meaning

Re: Dirty Area Status meaning

Re: Can ArcGIS Server host multiple Utility Networks?

Re: Can ArcGIS Server host multiple Utility Networks?

Re: Make the Network Properties Pane Non modal and dockable

Re: Getting Started with the ArcGIS Utility Network - Explore connectivity associations

Re: The Utility Network must be version 5

Re: Update Subnetwork Bug

Re: Validate Network Topology Error

Community Staff Champions