nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Mettre à jour le sous-réseau et l'équipement désexcité

EdwardBlair

Bonjour -

Voici le scénario du réseau utilitaire : J'ouvre un fusible protégeant un point de dérivation monophasé sur le feeder ABC123. Je valide et enregistre la modification, arrête la modification et mets à jour le sous-réseau pour ABC123. Les entités que j'ai désexcitées en ouvrant le fusible ont toujours un nom de sous-réseau ABC123, même si elles ne font actuellement partie d'aucun feeder.

Qu'est-ce que je manque ici ? Ou quelles autres étapes dois-je suivre pour que les entités désexcitées soient assignées à un sous-réseau 'Unknown'.

Merci d'avance pour toute information.

Trouver plus de publications taguées avec

Accepted answers

All comments

LynnMoeEsri

Hi Ed - I wonder if you are running Update Subnetwork in a version. If so, try posting your version and running Update Subnetwork in default and see if 'Unknown' is then listed in the subnetwork name field.

EdwardBlair

Hi Lynn -

I *am* running Update Subnetwork in a version. I'll give the post and update in Default a try. Thanks for the suggestion!

DamienPyne

We have seen this, and raised to Esri. We had been advised this is "as expected". Our workflow advises the user to use the subnetwork line to review for the update.

You should see these features IsConnected value updated, and when you run IsConnected the subnetwork should then update to unknown.

EdwardBlair

This is "as expected"? Really?? Pretty confusing. I'll try the IsConnected.

Thanks much Damien for the reply.

DamienPyne

I guess its similar to a load shift. You have subnetwork 1 and subnetwork 2. To update the changes of the shift where SN1 is now part of the old SN1, you need to update both SN1 and SN2. If you only update SN2, then there is a section not yet updated.

Same theory here. You have a section of network not part of that update (ie your deenergised features), and the IsConnected will clear the SN value and flag these as isconnected = False. Ie they are isolated network objects.

GIS_kiwi4

@EdwardBlair - I am noticing the opposite of what you have suggested.
I have opened up a fuse. After the subnetwork update -
The fuse has the SUBNETWORKNAME field populated but all assets downstream of it have the SUBNETWORKNAME blanked out.

Screenshot 2026-02-23 113909.jpg

After "closing" the fuse and updating the subnetwork you can see the subnetwork name restored. (Ignore the "::" that an unrelated issue )

Screenshot 2026-02-23 114255.jpg

MikeMillerGIS

This is as expected in a version with eventing off. This is caused by how Branch versioning works. In a version, a row only exist if it was modify. So take Eds example

1: Create Version - At this point, there are zero records with that branch ID

2: Open Fuse - This edit adds a new record to the device table with the updated attributes. The Branch ID of that row references this active version

3: Save/Validate/Update Subnetwork- Since there is only one row with this versions branch ID, this is the only record that can be updated. If Update Subnetwork were to update the affected down stream features, those edits would show up in default.

Hopefully this helps. Running a subnetwork trace will display the correct results.

EdwardBlair

Mike -

Thanks for the explanation.

As you mentioned, in our experience (so far) the subnetwork trace returns expected results. Unfortunately this is also, at least initially, another source of confusion. I've got a trace telling me one thing and subnetwork name values telling me another.

EdwardBlair

Well... that's what we would want. Mike Miller stated that what we see is expected behavior *in a version with eventing off*. Is it possible that you are performing the update subnetwork in SDE.Default? Or that you have eventing enabled?

Thanks for the reply!

EdwardBlair

Hi @DamienPyne -

It seems like enabling "eventing" might enable the responsiveness to device status changes we now see with ArcFM Feeder Manager (in 10.x) . But it also seems there are pros and cons to this. Have you purposefully avoided enabling "eventing"?

Thx,

DamienPyne

I had to go digging to confirm. Yes we have eventing off. This was not an option with UNM v3 which is where we started. Its one of those options and enhancements we did not go to when we uplifted to v6.

EdwardBlair

Thank you very much.. we will have to dig into eventing and see if it will help us. Your feedback has been really helpful.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.