Latest Contributions by RonnieRichards

Thanks for the clarification @SSWoodward ! Never knew FLOAT was intended to be limited in the Enterprise GDB as the stated in the documentation. ArcGIS field data types—ArcGIS Pro | Documentation For some reason ArcMap always created float as 38,8 numeric in SQL Server and was surprised to see Pro was different scale/precision but see it now aligns with the legacy desktop documentation.  ArcGIS field data types—ArcMap | Documentation RonnieRichards_0-1779378738966.png   ... View more

@Michele_Hosking  It looks like numeric/double is fixed and now defaulted to 38,8.  Float seems to still be broken with default still at 6,1 but can be changed but the resulting type in SQL Server is still showing numeric in our environment. RonnieRichards_0-1779308151959.png       ... View more

Yes the missing fonts were converted to glyphs and injected into the vtpk without issue. This also required updating the p12\resources\info\root.json file with relative paths for all the pbfs. It works but unsure if we will continue this practice.  ... View more

Hello @JordanCarmona  What I meant by NOT going out to cache is Pro does not warn specific fonts won't be included in the cache bundle. We are finding this out manually after entering the style editor. For example a map creator used Arial Narrow and Arial Narrow Bold in some label classes. We create and publish the vtpk only to find those 2 fonts are not included? Why? We are not sure ... but it still would be helpful to have some warnings/validations or alerts upon creation of the vtpk these fonts would not be bundled.  This causes problems because the Pro author assumes the cache would be represented similar and in these case of the missing fonts, it doesn't and the tolerances require additional layer style tweaks in the editor (not pro) to make them work.  ... View more

@NathanMellor I know it has been 8 years since your post but this was something we were looking to do. In the end we wanted to package fonts and fix the problems with map extent. Pro does not do this consistently or provide any information what is NOT going out to cache or how to set the extent.  Luckily we stumbled across settings which will repackage and those are to use zip format but without the compression (level 0). It looks like this in 7-zip. So far this is working great in 11.5 ! RonnieRichards_0-1755532258708.png     ... View more

@Michele_Hosking you are absolutely correct with that!! This appeared to happen in the 3.2 release when the other GDB changes were introduced. Pro 3.2+ double data types are created as 7/1. This release also seems to break the FLOAT datatype. Tables created prior to 3.2 release double data types were defined as 38/8. RonnieRichards_0-1754612193053.png RonnieRichards_1-1754612205281.png RonnieRichards_2-1754612219840.png ... View more

@SSWoodward  @mpboyle is correct I don't think the option to specify precision in the Create Feature Class/Table wizards have ever been present in a Pro release.  The right click within an Enterprise Geodatabase in Catalog is one of the quickest navigations for new tables in Catalog. Right click create a new table and import from a template.  As an educator students are going to gravitate to the context tools before searching for geoprocessing tools so please make them behave consistently. Your future ArcGIS Desktop users will appreciate consistency and really enjoy creating GIS data models in the Enterprise GDB especially considering this requires Professional Plus licensing to "create" in an EGDB. This was a solid workflow in ArcMap ... View more

@Michele_Hosking Agreed this is frustrating! To provide a little more background to some of what you encountered: File, Mobile Geodatabases and GeoPackages do not technically have decimal data types with precision, they are all considered float which is why you get the 38,8 definition.  However the experience of designing data models in the Enterprise geodatabase has been completely destroyed. Creating data models using templates used to be a very productive workflow, now it no longer works due to this 7.1 madness. At our organization we now create all of our data models in unregistered tables using the RDBMS tools and then register them with the geodatabase when confirmed. Any changes to these then encounter all of the issues you and others shared on this thread. We use backend rdbms tools to modify column definitions in non-versioned environments due to all of the hoops required using Pro management tools.  Educating new users and staff with the work arounds and other approaches make very little sense, please just fix this tool to work like it used to allowing users to alter decimal precision where applicable.    ... View more

ESRI support has confirmed the issue we are dealing is related to the same bug. Our automated work-a-round for this was to restart the ArcGIS Server windows service after 10 minutes of windows start-up.  We then deleted all of the portal registered data stores items and this problem went away for us. The backend registered data stores in ArcGIS Server still work for our environment.  ... View more

Thanks for this @DenisLalonde ! This is very helpful but does not align with exact scenario we are running into. Curious for your environment are you using any Registered Data Stores (Database)? ... View more

We are having the same problem once we upgraded from 11.3 to 11.4 with DynamicMappingHost. Although additionally for us many of the standard system and utility soc's are not starting either. If we give the systems some time and restart ArcGIS Server after about 8-10 minutes everything comes up ok.  In a brand new install of 11.4 this startup symptom did not exist but as soon as we added a registered data store for a SQL Enterprise gdb then this situation started occurring. We delete the registered data store item from portal, restart and everything comes up healthy? So in these tests we have not even implemented any custom services using SHARED instances yet. We have delayed the start of ArcGIS Server service which helps get the services healthy and not have to baby sit after reboots but we need a permanent fix. ... View more

I submitted this because ran into a bug in Pro 3.2.2 with all numerics fields from import being created as numeric(7,1) Template Table used to import fields and precision and scale are not respected for any of them, resulting in all 7,1 values including a float data type! Please fix this stuff!! RonnieRichards_2-1712862611747.png RonnieRichards_3-1712862615002.png ... View more

In past releases of ArcGIS it was possible to modify the precision and scale for numeric fields when importing fields from another class during New Feature Class or New Table create screens.  In the latest versions of Pro 3.2.2 it appears the numeric precision and scale are not shown and the result seems to have issues maintaining the precision/scale from the import. It would be nice we could fix these issues before the tables get created incorrectly...  Please restore the ability to edit the numeric precision and scale, we can still edit text field lengths on the fields screen. RonnieRichards_0-1712861704493.png   RonnieRichards_1-1712861709054.png   Thanks Ronnie ... View more

Yes please make this consistent with the legacy arcpy mapping analyze as well as the current creategeocodesddraft. It does not make sense why this was changed and inconsistent with geocode drafts. CreateGeocodeSDDraft—ArcGIS Pro | Documentation RonnieRichards_0-1712599128432.png     ... View more

Hello @FredSpataro no never figured this out. Ended up checking the analysis messages during the stage process similar to the examples they have published in the MapServiceDraft help. However this is not very desirable as you describe it takes for ever for large maps with unregistered data sources to copy to local data... and then for us to fail the script because this may not be the desirable result. Not sure why the difference in this workflow compared to Geocode Drafts or legacy MXD publications but certainly is not optimal and different than the UI experience.  ... View more