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; } } }

ERROR 160874: The utility network association already exists

MarianoDiNapoli

Hi everyone,
I'm working with Esri Utility Network on ArcGIS Pro 3.3.1 and I have a technical question about a specific behavior I keep running into during the Asset Package deploy process.

**Background**
My typical workflow is:
1. Deploy the Utility Network from an Asset Package using the Asset Package To Geodatabase tool.
2. Go back to the Asset Package to make configuration changes.
3. Re-run Asset Package To Geodatabase against the same geodatabase.
At step 3, the ImportAssociations step consistently fails with:
> ERROR 160874: The utility network association already exists.
> [Duplicate association found. Association with FROMGLOBALID: {…} and TOGLOBALID: {…}]
> Failed to execute (ImportAssociations).

My questions
1. What is the exact relationship between the two tables involved?
As I understand it:
- `UN_5_Associations` is the internal system table of the Utility Network, managed by ArcGIS, holding all active associations (connectivity, containment, structural attachment). The number 5 is the internal ID of the UN dataset within the geodatabase.
- `C_Associations` is a staging table included in the Asset Package, used as the input source by the ImportAssociations geoprocessing tool.
Is this understanding correct? Is there anything I'm missing about their relationship and lifecycle?

2. Why is `UN_5_Associations` not included in the original Asset Package?
When exporting a UN to an Asset Package, only `C_Associations` seems to be carried over — the system table is not included. Is this by design? If so, what is the architectural reasoning behind it?

3. Why does ERROR 160874 occur on re-deploy?
My hypothesis is that during the first deploy, associations are written into `UN_5_Associations` automatically as part of the apply asset package process. When re-deploying, ImportAssociations reads from `C_Associations` and tries to insert the same FROMGLOBALID/TOGLOBALID pairs again — finding duplicates already in the system table and throwing ERROR 160874. Is this correct?
What is the recommended approach to handle this UN → edit AP → re-deploy cycle without running into this error?

Current workaround
I've written a Python (arcpy) script that, before re-deploying, removes from `UN_5_Associations` all FROMGLOBALID/TOGLOBALID pairs already present in `C_Associations`. It works, but I'm wondering whether there is an official or Esri-recommended way to handle this scenario cleanly.

Thanks in advance to anyone who can shed some light on this!

Mariano

Najděte více příspěvků označených jako

Accepted answers

RobertKrisher

The warning you're getting about duplicated rows is caused because the asset package tools are detecting duplicate rows in the asset package. Because you are deploying the asset package to a new geodatabse, you cannot have conflicts between what is in the asset package and the target UN (because the target UN is empty).

When you run export to asset package the resulting asset package will not contain any UN_* tables, so we populate C_* tables so they can be used to recreate the data in the system tables when the asset package is deployed.

All comments

RobertKrisher

The UN_* tables are the system tables of the utility network, the C_* tables are the corresponding tables in the asset package.

You shouldn't be redeploying the asset package to the same geodatabase to make configuration changes, you have to deploy it to a new geodatabase. There asset package is designed to append new data and new configuration into a utility network. If you make changes to an asset package you must deploy it to a new geodatabase, otherwise you will end up with duplicated data and it's likely that most of the configuration changes will not be applied.

MarianoDiNapoli

Hi Robert,
thank you for your reply. I probably was not very clear in explaining that the geodatabase used for the redeploy is actually a new one. My main question was to better understand the difference between the two tables and, most importantly, why the UN_* table is imported when going back from the UN to the AP, since it is a Utility Network system table and not an asset package one. The error appeared because both tables contain the same information, so duplicates are detected. Looking at the solution, the UN_* table understandably does not exist there, so I was probably misunderstanding the origin of the data.
At this point, I believe this behavior is related to configurations created directly within the Utility Network.
In any case, thank you for your support.
Best regards

Mariano

MikeMillerGIS

Easiest way to think about it, is the Asset Package is the complete representation of the Utility Network, but serialized or represented in a series of visible tables. Running Asset Package to GDB always creates a brand new Geodatabase. The tools take all the rows from the C_Association table and format them into the format that Import Association requires(csv). You can see these files in the AP_Workspace folder. Can you post the entire message from the GP tool?

RobertKrisher

MarianoDiNapoli

Hi Mike and Robert,
my approach was to delete from the UN_* table the same identical items present in the C_ASsociations table, using a script. In any case, the generated error is the following:

ERROR 160874: The utility network association already exists. [Duplicate association found. Association with FROMGLOBALID: {1AE81AD3-C6F1-425D-9AF2-C144729D8DA7} and TOGLOBALID: {F6073DAE-0C3D-4B1E-9221-736095911AD6}], The table was not found. [Network]
Failed to execute (ImportAssociations).

As mentioned before, I had to run the geoprocessing tool to generate an Asset Package from an already configured Utility Network (I had to change different description of domains ). As a result, when I ran the tool, I ended up with the UN_5 table inside the AP.
This is why I was asking about the differences between the tables and why this issue occurs.
Thank you both.

Mariano

RobertKrisher

It sounds like you are staging and deploying your utility network in the same geodatabase as your asset package. this is not supported.

RobertKrisher

@MarianoDiNapoli btw, if all you need to do is update some asset type/asset group descriptions, you can do that on your utility network using ArcGIS Pro 3.7. You don't even need to disable the network topology. You can do this using the Design Views or the new Alter Subtype and Alter Coded Value Description tools

MikeMillerGIS

You should never get any UN_<DSID>_* tables in the asset package. If you do, the asset package tools will treat it like a stand alone table.

MarianoDiNapoli

Thanks @RobertKrisher and @MikeMillerGIS for the suggestions.
Mariano

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

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