Latest Contributions by RobertKrisher

If we deleted the rows from the table, then we have done our part. Some DBMS have another step you have to go through in order to free up the space associated with the old rows. ... View more

I recommend you check out the electric reading list, the first tutorial will give you a feel for how to model features in a utility network along with some of the benefits of a UN. Your features will be snapped and connected, ultimately traceable back to a circuit breaker that allows you to see which circuit they belong to. So three circuits in a vault would be three separate lines, each belonging to a different circuit, that are drawn passing through a vault. Likewise if you want to model all the connectivity within a vault you can do that as well, as long as you draw them in a way that maintains their connectivity and, ideally, maintains visual clarity. If you can you provide some examples of what data you're dealing with currently, we can make better recommendations about what will and won't work in a GIS (and/or the utility network). Its faster to capture data in an asset package, but you bypass all the validation/snapping/connectivity of a utility network. If you have a utility network that is fully configured and works well for your needs you can capture data directly in that model, but you will need to validate as you go. ... View more

You can run the tool with versions still in the system, most customers will. If there are many versions that aren't reconcile or contain conflicts, the tool won't prune as many records because of the referenced moments. This is discussed in the page I linked. Check the number of rows in the table before, and after the prune. Just deleting all the rows from the branches table is going to leave information orphaned in the system tables. You don't need to do it by hand through the service, but you do need to use either a GP tool, script, or SDK to use our APIs to reconcile (or delete) the versions. Any versions with conflicts will need to have their conflicts resolved in order to remove the referenced moments from the default version history. Finally, there are likely some configuration changes you can make to your subnetwork definitions to reduce the size of your subnetwork lines. Things like making sure you're not including service lines as part of the aggregated geometries for each tier of your network can significantly reduce the size of each line and the speed with which that table grows. Even thought a feature's shape isn't included in the aggregated geometry, it is still included in all the functions and calculations for the subnetwork. ... View more

I just verified that this works when publishing a feature service that contains a single feature class with attribute rules configured using ArcGIS Pro 3.5 final and 3.5.2. Make sure that you meet all the requirements for publishing error tables in the Share datasets with attribute rules topic in the ArcGIS Online Help. ... View more

@JeffBlake make sure you've read the requirements on this page: Prune branch history—ArcGIS Pro | Documentation. The most likely scenario is you have versions and/or conflicts out there that are preventing the tool from pruning any inactive records. ... View more

@PierreloupDucroix  Change the group template to use a line tool instead of a point tool:   Then you'll have access to all the builders for lines:   ... View more

Capabilities of the service are often controlled by the database, dataset, and server of the machine hosting the service. Do the layers in service B have Global IDs? ... View more

@YulissaCamacho I just confirmed that you cannot assign more than one network attribute to the same field on the same class. Once a field is set to be a network attribute, it no longer appears in the list of available fields. Network Attribute Assignments   Set Network Attribute Tool   ... View more

If edits are failing, there really should be something in the ArcGIS Server Log. Try it with the log level set to warning (to make it easy to find any errors). Setting it to debug level can help you track it down to something like an attribute rule firing, but be prepared to sift through a lot of edits. If you haven't already, consider logging a case with support on this. ... View more

Adding to what @MikeMillerGIS  said (and going against what @gis_KIWI4  said in his second response). You only want to have one network attribute assigned to the field. As long as the codes are the same, you can have different domains assigned to each subtype. As long as they have the same codes, you could use different domains for each subtype of a class on the same field. I'm not sure if we allow you to assign multiple network attributes to the same field, but even if you did you are going to get yourself in trouble when configuring your subnetwork definitions. When possible you want to have similar subnetwork definitions across your tiers, especially when features can exist in multiple tiers. If you don't, then when we are trying to mark subnetworks as dirty we don't know which tier's subnetwork definition to use and this can result in unexpected behavior. ... View more

Are you looking for the first downstream device that is a smart switch OR open? or that is an open AND a smart switch? When I ran a trace on a device with terminals and left its terminal ID blank, I got an error. In terms of how filter barriers are applied, they have a special behavior when dealing with devices with terminals. They are only evaluated when we cross an internal edge of the device. This is why if you start at the downstream edge of a protective device we will stop on the device, but if you start on the upstream edge, we return the upstream protective device. Its this same behavior that keeps us from treating distribution transformers as potential barriers (unless you cross from LV to MV). ... View more

Do you have any constraint attribute rules configured on the dataset? Check the ArcGIS Server logs for any warnings or errors. ... View more

Associations are great for when you want things to be connected without showing lines, or without having to draw/maintain extra pipes. In this scenario, I would lean towards drawing the pipes so it's immediately obvious how things are connected. Regardless of the approach you take, because you are dealing with subnetwork controllers make sure you have all the rules set up for the correction junction-junction or junction-edge connectivity to allow the correct terminals to connect. If you do need to add rules, consider copying your data out to a local mobile or file geodatabase to test out the changes until you have all the configuration you need to get everything connected and all the subnetworks tracing. It may take you a few tries to get everything squared up, and it's easier to do it in a local geodatabase where you don't have to worry about stopping services and interfering with users trying to get work done. ... View more