We are going to create multiple utility networks. Are there recommendations around having multiple EUNDM schemas in the same ArcSDE instance (one schema per network) or will that cause conflicts and we need to create a separate ArcSDE with a single EUNDM schema in it?
Other info:
@Anumita the most common approach we see for this is to create separate users and schemas for each utility network. Each utility network then also gets a dedicated feature service. It is possible to have multiple utility networks from different services in the same map, but there are some known issues with some of the tools in the UI with that setup.
Hey Garima! I even had to retest this to make sure as I typically load multiple UNs as a different database user if they are in the same geodatabase.
It looks like you can create multiple UNs in the same geodatabase as the same user. We properly handle the naming of the geodatabase objects so they are unique and there are no name collisions.
I do not know if we have a best practice recommendation for organization in the geodatabase. Go with what you can best manage without getting your datasets confused. Depending on the configuration, the UN data model can get complex with relationship classes, tables, multiple domain networks, etc. This may be easier to maintain with a level of isolation for administrative and backup purposes.
A single Portal Utility Network Owner can simplify management for multiple utility networks with different database owners. But if security and isolation are crucial, using separate portal users is the way to go.
@RobertKrisher
There's no technical limitation one-way or the other. That comes down to an organizational decision of whether you want a single portal user to administer both datasets.
In addition to having separate users owning the schema in the database, would you also create a separate portal user to own each network or would a single user suffice?
Thank you @RobertKrisher Much appreciated!
Hello @MelissaJarman During a recent deployment of two separate Utility networks within a single Enterprise geodatabase using the same database user, we encountered a naming conflict involving feature classes.
When deploying the second Utility network, the system automatically appended the "_1" suffix to the names of feature classes that are part of the Structure network.
This inconsistency caused the subsequent "Apply Asset Package" process to fail, as the Asset Package did not contain feature classes with the "_1" suffix.
Our research revealed that there may not be a direct method to modify the names of feature classes involved in the Structure Network. Any changes made to the Asset Package during the "Stage Utility Network" process seem to be disregarded.
We did some research and it looks like there might not be a way to change the name of feature classes participating in Structure Network. As any changes made to the asset package does not get acknowledged during ‘Stage utility network’ tool.
To maintain two distinct Utility networks within a single Enterprise Geodatabase, should we consider the following alternatives:
Thanks, Melissa! Appreciate the extra step of testing with the confirmation.
@MelissaJarman - you're the pro here. 🙂
Thank you @SSMIC3038 I thought so too but i want to let someone from Esri chime in and confirm.
One database can have one utility network with multiple domain networks within. Multiple utility networks on one database doesn't work, I'm assuming it's due to reserved naming conventions.
To date I've never found any material from ESRI on how to create multiple domain networks within one utility network, which is odd because they promote this so much in their marketing. With quite a bit of effort I've managed to get multiple domain networks in a single utility network up and running, some literature from ESRI would be nice.
I also have a couple of threads on this topic and they've never received a comment, so not much help available.
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
