Inconsistency between Subnetline et Subnetwork status

[PierreloupDucroix]

Hello,

We have found that there is sometimes a difference between the isdirty value of a subnet line and the isdirty value of the subnet.

Ex: Here you can see that the same subnet has a status of False in the FC subnetline row (left) and True in the subnetwork table (right). And the Update Subnetwork toolbox allows us to update the subnet, unlike the "Find Subnetworks" panel (because I assume the tbx applies to the subnet table and the panel applies to the FC subnet row)

Also the Export Subnetwork does not propose this subnet (obviously because it is dirty) : 

Looking at REST endpoints, I can see the same inconsistency:

SubnetLine : 

Subnetwork : 

The problem is that we are checking the FC subnet line to find the updated subnets, validate them if necessary and export them into an ADMS. We will now have to rebase the tool on the subnetwork table (500002) instead of the FC.

UN V6 / AGS 11.3 / Pro 3.3.6

Before I log a case to the support, does anyone else have a similar behavior ?

[RobertKrisher]

The subnetworks table is the more reliable way of determining status, especially in networks with multiple subnetwork controllers.

[PierreloupDucroix]

Isn't the status supposed to be consistent between the subnetwork line and the subnetwork ?

[gis_KIWI4]

Hi @PierreloupDucroix, 

That was my understanding too. 
I looked our data and I couldn't find any records that showed the same inconsistency as the one you have highlighted. The update subnetwork operation should set the Subnet line FC status = 0

https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/subnetworks.htm#:~:text=When%20th....

Just wondering if you have  Manage IsDirty parameter set correctly. This may not be the issue because you mention that this only happens for some instances. 

[PierreloupDucroix]

Of course, we manage the "isDirty" state for each tier.

The problem isn't that updating the subnetwork doesn't update the subnetLine FC ; it does if I manually update the subnetwork in Default.

The problem is more related, I think, to how a subnet update in a version applies to the subnetLine feature once posted to Default. I think that in some cases, posting a subnet updated from a version to Default will set the state to 1 in the subnet, but leave it at 0 in the subnetLine…

[RobertKrisher · Accepted solution]

@PierreloupDucroix you are correct in that the behavior is slightly different when posting edits from a version. If the subnetwork or subnetwork line is modified in the version we will mark it as dirty when it gets posted because we know that there are changes that happened to it in the version that mean it needs to be processed in default.

As an example, if you create new features in your version and run update subnetwork, they will have their subnetwork name populated and the subnetwork line will be updated to reflect the new features in your version. After you reconcile and post your version to default, there is no guarantee that those same features will be connected, so we make you rerun update subnetwork to ensure everything is clean and connected.