Latest Contributions by RobertKrisher

Transformers have terminals (high and low) that should correspond to Node1 and Node2 in your example. If you use Export Subnetwork (or Trace) to export the connectivity of each subnetwork to a JSON file you can just look at the resulting file to see the layer, global id, and object id of each feature connected to each terminal of each transformer. Here is a snippet of a JSON file that shows this (additional attributes, asset group/type, etc are elsewhere in the JSON file):     {       "viaNetworkSourceId" : 9,       "viaGlobalId" : "{CA7E882F-ACCE-4A2F-8A59-18D0EB60DB09}",       "viaObjectId" : 6127,       "viaPositionFrom" : 0,       "viaPositionTo" : 1,       "viaGeometry" : {       },       "fromNetworkSourceId" : 9,       "fromGlobalId" : "{CA7E882F-ACCE-4A2F-8A59-18D0EB60DB09}",       "fromObjectId" : 6127,       "fromTerminalId" : 7,       "fromGeometry" : {       },       "toNetworkSourceId" : 9,       "toGlobalId" : "{CA7E882F-ACCE-4A2F-8A59-18D0EB60DB09}",       "toObjectId" : 6127,       "toTerminalId" : 8,       "toGeometry" : {       },       "viaNetworkSourceName" : "ElectricDevice",       "fromNetworkSourceName" : "ElectricDevice",       "fromTerminalName" : "2wXFR:Primary",       "toNetworkSourceName" : "ElectricDevice",       "toTerminalName" : "2wXFR:Secondary"     }, ... View more

A screenshot of the features/errors would help in understanding the problem. Seeing exactly where the errors are in relation to the features will help understand what the problem is, and whether it is caused by these rules or something else. If you want to enforce an EJE rules, then you should not have JE rules that overlap with them. Because you have both this means that you can place a Riser between two primary conductors as well as between two transformerstationswitchgear. If you only want the riser to be able to exist between the primary conductor and the transofmerstationswitchgear, then you need to remove the other rules. ... View more

The SUPPORTINGSUBNETWORKNAME field applied to all applicable domain classes has properties that do not match those expected by the system (on creating a Utility Network or upgrading a dataset). When the SUPPORTINGSUBNETWORKNAME field is created, isRequired must be -1 which means True, and isEditable must be 0, which means False. In this data, isRequired is 0 and isEditable is -1, which caused the failure. The SUPPORTINGSUBNETWORKNAME field is not created until Utility Network Version 5. Removing these fields from the various classes allows the upgrade to be run successfully from Utility Network Version 4 to Version 5, or 6 (which then re-adds the fields in a supported manner).   You should check the SupportingSubnetworkName field for the following classes for each Domain Network in your Utility Network (except the structure domain): Device EdgeObject Junction Junction Object Line ... View more

If you want to start synchronizing information between all of these database, the best thing you can do is to create a single unique identifier that is shared between the system that uniquely identifies each feature. You could add a GUID column (not a global ID column) and use that. If you then have a unique GUID for each object in your database, detecting changes to classes and relationships becomes much easier. You can detect new features, missing features, modified features. You can also audit relationships by looking to see where the parent/child features aren't related or are related to different objects. If you have to do a binary comparison, you could look at using a utility to calculate a checksum or hash using the contents of a file, then compare the results of the hash. You can find several examples of ways to do this using python or powershell online. ... View more