topic Re: Add Network Attribute (Trace Network) Issues in ArcGIS Pro Questions

Add Network Attribute (Trace Network) Issues

EdwardBlair — Thu, 02 Jul 2026 16:42:23 GMT

Hi –

I’m seeing unexpected behavior after I add a new “Network Attribute” to a Trace network. Here are my steps.

1. Disable Trace Network Topology

2. Add a new Network Attribute named “NormalPosition” of data type Long

3. Use Set Network Attribute to assign this network attribute to a (Long) field named NORMALPOSITION_A

4. Enable Trace Network Topology

5. Change the value of NORMALPOSITION_A on a feature from “Closed (1)” to “Open (0)”. Save edits and validate topology.

6. Perform a trace with a barrier defined to stop at NormalPosition = “Open”. The trace stops at the newly opened device, as expected. All good.

7. Change the value of NORMALPOSITION_A on the same feature back to “Closed.” Save edits and validate topology.

8. Perform a trace with the same barrier condition and it STILL STOPS at the device which was changed to “Closed”

Any suggestions on what I might be missing would be much appreciated.

Thx,

Re: Add Network Attribute (Trace Network) Issues

Robert_LeClair — Tue, 07 Jul 2026 20:41:13 GMT

This behavior is almost always because the trace is still reading the old network-attribute value stored in the network topology, meaning the edit didn’t get fully incorporated by validation.

Try these checks:

1. Validate the full dirty area (not just current extent)- A feature isn’t guaranteed valid “until the full extent of the feature’s dirty area is validated.” If you validate by extent and don’t fully cover the dirty area, tracing can still use outdated attribute values.

2. Confirm a dirty area is created for the attribute change - Network attributes used by tracing are stored in the topology; when the source field changes, a dirty area should be created and then validation updates the stored value used by traces.

3. If this is a Utility Network tier/subnetwork workflow - Depending on tier configuration, validation may mark subnetworks dirty and you may need follow-on QC (for example, Update Subnetwork / evaluate rules) for analytics to fully reflect changes.

4. Barrier value: code vs description - Make sure the barrier is evaluating the stored numeric value (0/1) and not a coded-value description string (“Open/Closed”).

Re: Add Network Attribute (Trace Network) Issues

EdwardBlair — Tue, 07 Jul 2026 23:02:02 GMT

Robert -

Thank you for the reply.

To be clear, this is a "Trace" Network, not a "Utility" network.

That said, I've followed your steps exactly -- to the point of making sure there are *no* dirty areas in the database after completing my edit and validating and saving. I still get the same result. If I change the normal position of a device from open to closed, then perform a trace which has a barrier condition of normal position being "open", then the trace still at the newly closed device.

FWIW - I've also made sure that the domain codes are as expected; Closed = 1; Open = 0.

Re: Add Network Attribute (Trace Network) Issues

KevinBrown6 — Tue, 21 Jul 2026 15:22:40 GMT

I'm seeing this same behavior - validating full extent, Trace results don't honor updated values. Using Pro 3.3 on a file gdb.

Re: Add Network Attribute (Trace Network) Issues

RobertKrisher — Thu, 23 Jul 2026 19:59:46 GMT

@EdwardBlair , @KevinBrown6 disabling the network topology shouldn't be required to see the change. I see that Ed already has a case open for this, I expect this to be confirmed as a bug soon.

Re: Add Network Attribute (Trace Network) Issues

EdwardBlair — Thu, 23 Jul 2026 20:09:15 GMT

Hi Robert -

Thanks for weighing in on this. Its become a pretty important sticking point in our implementation.

Re: Add Network Attribute (Trace Network) Issues

RobertKrisher — Thu, 23 Jul 2026 22:13:48 GMT

@KevinBrown6 since you are also experiencing this problem can you please open a case with support and get attached to the bug. The bug number is BUG-000186555.