Latest Contributions by Andy_Morgan

Valuable information. Thanks so much! ... View more

Even though both replies were the needed answer, I'm marking Mike's answer as the solution simply because it had a screenshot that helped me see where to go. Thanks, Robert! ... View more

Thanks for the suggestion. I had actually tried the Modify Terminal Connections tool a few days ago in my many rounds of attempting to lessen the number of errors in bulk, including the use of add/set terminal configurations. I must not have noticed Modify Terminal Connections helps. I ran as shown below: Modify Terminal Connections   Domain Network: Water   ☑  Honor digitized direction   ☑  Keep existing terminal values Now, after enabling network topology (with "Only generate errors" checked), I have a total of 10,129 errors. Much better already. This eliminated the vast majority of those ambiguous rule situations. Only 61 code #512 errors remain. The other categories of errors are mostly cases where we need to either define the allowed E-J relationship with a new rule or else add fittings where they don't exist at certain types of intersections.  So for water assets, should I uncheck either or both of those options ("honor digitized direction" and "keep existing terminal values")?    I'll need to do this later for our sewer network. I would think sewer needs digitized direction honored since that's a one-way (sink) path. ... View more

Awesome, thanks so much Paul. I don't have Pro 3.1, but soon enough I'll upgrade and try this out. This seems like a good solution for most people (...who care at all about precision/scale properties). ... View more

I'd gladly take a generic version with all Floats having P: 6, S: 1 (example: 42.5) and all Doubles having the current default of P: 38, S: 8.   But we (organizational level) may be upgrading our version of Pro to something higher over the next 6-12 months as Enterprise gets upgraded and UN comes into the picture. Would it make more sense to target untools for 3.1 for the RC? I imagine our whole organization will be on Pro 3.1 or higher before the end of the year. I may jump ahead from 3.0.3 to 3.1 for UN prep. Thanks. I realized my thinking was a bit narrow in terms of precision/scale for a Float. There is a limit for those values, but not everyone necessarily wants scale of 1 for their Floats. I'm not sure how you'd decide what's best for the average need (a precision of  5 or 6, maybe, with a scale of 1 or 2 at most?). Maybe you're saying you define a universal P/S for those two types. It would definitely be an improvement. I'm trying to represent others out there, too, hopefully.    ... View more

OK, last response. I'll accept this as an answer, but my conclusion is that everyone who builds a Utility Network on SQL Server (and some other DBMS types?) has two options for using Float fields: Accept the fact that your non-integer numeric fields are going to be Double with the default precision/scale (38/8) If you really want Float data type fields and you want all your fields added in a specific order then you must omit them from the AP. After applying the AP, you could run a script to add all your fields with the numeric data types having an exact precision/scale defined during that stage. If, however, you were to export your EGDB UN to an AP to start fresh with an AP having the latest properties, you might not be able to use this AP for pushing updates.     In #2 I assume this situation will cause Apply Asset Package to fail: "Elevation" field data type in Asset Package  "Elevation" field data type in EGDB UN Device FC  Float Double   Who really wants to go with option #2, though. It somewhat defeats the purpose of using an AP to me. ... View more

Same result here with my version of SQL Server:  changes over to Double at the "f_07_01" field (precision > 6). This clearly illustrates what happens in general when manually creating new fields. I was mainly wondering if anyone out there can confirm "Apply Asset Package" still converts from Float to Double in later versions of Pro / UN schema (3.1+). If I need to upgrade one of our test computers and run through the whole process on it then I will, but there must be many users already on 3.1 right now who have tried this. I'm not totally clear if you're implying the answer is yes (3.1 and higher also convert Float to Double). If that's the case, then I'm confused on how Apply Asset Package is not "explicitly upcasting the field" and yet the field is in fact different in the target EGDB.       ... View more

Paul, I really do appreciate the quick responses on this board. I'm using SQL Server: Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) While this is a development server hosted on a virtual Windows server, the SQL database is nearly identical to our production server where I'll eventually deploy our UN within 6 months. Here's the production server version: Microsoft SQL Server 2019 (RTM-CU19) (KB5023049) I'm trying to think if there is anything else special about what I'm doing. I don't want to waste anyone's time. Let me know if you think of anything else that might be different from the normal scenario. Even though FGDB don't support scale/precision, it still surprised me that it was casted differently for this particular process/tool. I will eventually upgrade Pro to 3.1 and could re-try this process, but I figured others out there with 3.1+ already know if it does or doesn't work. ... View more

First of all thank you so much for summarizing these steps and offering pointers for us newbies. I've been researching this topic and slowly preparing to migrate our water and sewer utilities from Geometric to Utility Network. I have a lot of work ahead over the next 6+ months, but at the moment I'm starting with a (virtual server) development level Enterprise/Portal environment and creating sandbox eGDB's to slowly walk through asset packages and data loading with workbooks. If you don't mind, I have a few questions on what you posted. Maybe a follow-up question or two. These types of "lessons learned" are so valuable. The documentation is vast, ever evolving, and quite confusing at times...not to mention the dreaded feeling of encountering an obscure geoprocessing error that cannot be found anywhere online to offer a solution. I depend on my IT GIS co-workers for applying production schema changes, and it must always be done after hours when services can be stopped, digging into my own personal time. For these and other reasons I'm really concerned that if we don't have it right with the correct sequence for any given workflow it could lead to disastrous, hair pulling, schema change sessions from deployment onward. I'm concerned about how long it may take to perform simple changes, too. With an empty Asset Package (no data) it takes a few minutes to do anything. I cannot imagine how long it might take to execute something significant with the "Load Data" option checked, considering all the data we'd push back and forth during each round of changes. First of all, for context, please describe your GIS environment: ArcGIS Pro version? Enterprise version? Utility Network version?   When you say "a fresh export is best" you're implying every time you want to make any changes to the eGDB it's too dangerous to assume the Apply Asset Package will finish properly. What if I need to edit my own copy and then give to our IT GIS group who stores the latest FGDB copies on their server? Or as a backup in case I mess up? There could be many reasons, but the point is that the renaming of the FGDB is a bad idea or is any copy of the original export (i.e. same file name but different folder) possibly going to get corrupted?   Stage Utility Network vs Create Utility Network: I found with Pro 2.9 and v5 UN that it seems to work fine to use Create Utility Network tool, then apply the package to create the initial domain network objects.   The D_Configuration table is starting to make a little more sense so far. As for the Configuration category domain values, you mention the "4: Always remove when applied" option. I'm held back to an older version of Pro and therefore untools package, so I don't have those new Configuration domain values. Not sure how this impacts all your steps.   Generally speaking, will your recommended workflow cover any "normal" schema changes such as adding, removing, renaming, or changing the data type of feature class fields; removing or updating a subtype; and adding/updating/removing an asset type in the domain? When, if ever, must we go to these great lengths in the link below to completely delete the entire eGDB and re-create (with the help of DBAs)? This is absolutely terrible if such steps are truly needed from time to time.  How to apply revised asset package to the same utility network I don't know who has it right between everything I'm reading. So many scenarios and opinions. Surely many other people feel equally concerned about understanding the sequence of steps and getting off on the right foot from day 1 of production deployment.  Thanks again. ... View more

Hi Jack, What about developers who have nightly automated processes like Python scripts and/or .NET console apps that update attributes or other data in UN feature classes? Will ESRI allow us to purchase an extra UN user type extension for a "headless (service) account"? It would not be used anywhere other than for a few scripts that run once a day. I understand headless accounts are prohibited in terms of sharing a license to multiple individuals, but if we need to have a separate account other than our own, with a password exposed in a script, that would mean the need for a service account, per se.    ... View more