Latest Contributions by RobertKrisher

As long as the field isn't associated with a network attribute or something required by the utility network, you can do this the same way you'd alter any other field in a geodatabase. The Design view for fields or the Alter field tool. Edit: @VishApte_NGIS mentions below that if you just switch a field from lower case to upper case, it will not change the field. This means you must alter the fields(s) twice, once to make it upper chase (with an extra adornment like 1) and a second time to remove the adornment. To make this easier, consider using the Alter Fields (multiple) tool to make the two calls. ... View more

@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. ... View more

You can do this in the Field Design View to change them in the geodatabase, then any time you add that feature class to a map it will use the field alias. If you need to change MANY field aliases or domain descriptions, you could consider using the D_Rename table. If you have pre-existing maps, this change will not automatically apply to the layers in those maps. Instead you must manually alter the Field Alias on each feature/subtype layer, as well as any popups that have overwriten the default alias of the field. Something like the utility network properties extractor can make this process easier because it allows you to export properties to a file, adjust them, then re-import them. You can also use the Paste Properties command on a layer to paste the field properties between an already configured map and an existing map. Because of this it is best to get your field aliases figured out in your data model and initial map before you start making too many additional maps. ... View more

Disabling and re-enabling the network topology on a regular basis is going to have some long-term performance implications, and you shouldn't need to do that. I'd make sure that going forward, you're just always logged into portal, and if you run into any strange behavior, make sure you're logged into the right portal/service, restart Pro, and hopefully that fixes it. If you find the experience of editing using the web map from Portal acceptable, then that's fine. There's a lot more you can do with a desktop map in ArcGIS Pro than you can do with a Web Map in Map Viewer, but you aren't relying on any of those capabilities so you're fine (display filters, layers with multiple definition queries, etc). ... View more

1 - I assume you're synchronizing customer data to this table? We recommend that you avoid any kind of operation that would require you to completely truncate and reload network data. We usually see customers putting the link to the customer data in the network, but storing the customer details (which shouldn't be editable in the GIS) in separate, un-versioned tables that can be freely modified/truncated by an external process. 2 - The system only lets you run truncate table on simple features. Because this table has a controller dataset (the utility network) it is not considered simple. 3  - I was surprised to see we let you unregister the table as versioned, this puts the system in an inconsistent state. That is to say that the system tables may still contain historical or versioned data for this table, even though the table itself has removed that information. ... View more