Latest Contributions by TimMinter

edit:  What is this, how you say, "ArcMap"?  I suppose my ArcGIS Pro Idea is related to this thread, but I don't see how it fits here in mid-2022. original: Open a table > right-click a field that interests me > View Field Metadata > opens the metadata at that field tag.     ... View more

Nice!  Thanks @KoryKramer! ... View more

Hi @John_Spence & @jsarthur, Good discussion above.  Under my standing "I really don't know anything" principle, I'd like to know more about the hugeness of the shrinking eGDB no-no.  If you can point me at some help documentation, technical articles, blogs, etc. that might be easiest.  Just chiming in with a few items: Usage - Vector feature classes, tables, relationship classes, feature datasets, time-enabled data, that sort of thing.  No or nearly no raster or other data types in the big (-ish) databases.  Relative to other data collections I've helped manage during my career, I don't consider these databases to be "heavily used" from the perspective of total number of requests over time and concurrent connections.  They are used enough that performance problems are noticed and communicated. Recovery model - 'Simple' for the databases we need to shrink.  We mostly use these as OLAP databases and just don't care about the logs much at all. Performance - ArcGIS Pro PerfTools suggests that things are going about as well as can be expected for object-relational handling of the data given our computing environment resources (storage, db servers, network, etc.).  We haven't noticed any unexpected negative performance effects related to shrinking the database.  During larger data loading activities, we expect and experience some performance hit as auto-grow does its thing.  This touches on why we shrink - one update we do loads ~600 million records as 'new' tables and feature classes, builds indexes, statistics, etc. over a fairly long time stretch.  In order to minimize availability impact to staff and systems, we switch out the 'old' with 'new' during a brief maintenance window, ensure everything is working as expected, then delete the 'old' object.  That leaves a bunch of unused storage that unnecessarily costs us money until the next update.  Maintenance - Yes, we regularly rebuild indexes, analyze, compress, etc. as needed.  We have a lot of truncate/append or simply append ETL activity as we move record updates into static schema in the eGDB. Metadata - Nice.  We've started to configure ArcGIS to not store GP processing history in the metadata, but not consistently across all machines that do the work.  Thanks for the link to that article.  We'll investigate to see about a cleanup and keep getting our house in order. Cheers, tim ... View more

HI Bill, Unfortunately, no.  I need a way to inject changed table schemas, including field order, into a relatively static enterprise geodatabase schema that uses db views to ETL data from an incoming spreadsheet that occults the source system schema (it shall forever be unknown to me/us) to a product set of enterprise geodatabase feature classes and tables that staff and various apps/systems use.  When the source system has schema changes that impact my ETL, I have to go and jiggle the staging tables that receive the spreadsheet content, ArcGIS-friendly tables with curated field definitions (and order), and the db views so that I don't have to change the schema for the product feature classes and views and bust a bunch of stuff.  Whew. My idea above would help because I could pop open the Add Fields (multiple) GP tool in a model, adjust the field definitions (and order), generate a schema that matches the source system changes, and carry on with the change.  As it stands, I can do that, but it takes days and thousands of clicks to set it up the first time.  When there are major source system changes, a fresh setup helps avoid errors.  If I could point the tool at the staging tables when setting up, then far fewer clicks would be involved and the opportunities for errors decrease. tim ... View more

Hi Edith, Concur!  I have one dataset with 7 feature classes and 7 tables that totals out at ~600m records.  I try to do most of my work in SQL Server, but have to head up to object-relational software land (ArcGIS) occasionally to do stuff.  Pokey slow, and in order to get anything done in human time requires very careful arrangement and application of computing resources and judicial use of ArcGIS functions. cheers, tim ... View more

Running ArcGIS Pro 2.7.3 as the 'geodatabase administrator' account, using "Enable Enterprise Geodatabase" GP tool after creating SQL Server 2016 database per the instructions here: https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/manage-sql-server/setup-geodatabase-sqlserver.htm#ESRI_SECTION1_0CB5A7EBA7EB4F69AA7180F0FA84779E https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/manage-sql-server/privileges-sqlserver.htm#ESRI_SECTION1_48345263705D453984B45C73811C1C56 ...the GP tool finishes and reports success.   However, when I try to interact with the database connection, ArcGIS Pro tosses up: Sometimes, but not always, I can run ArcGIS Pro as the 'data creator' account and paste a feature class into the database. After completing this step, I can close ArcGIS Pro running as 'geodatabase administrator' account, then start ArcGIS Pro as 'geodatabase administrator' account and everything appears to be working correctly. Sometimes I get stuck here. Have any of you run into this, and do you have any ideas how to have a consistently pleasant and error free experience when enabling enterprise geodatabases? thx, tim ... View more

@jcarlson, @KoryKramer  - thanks!  I was hoping for immediate gratification over extended longing, and you two delivered!  Apparently, I need to learn some new terminology in order to find this stuff. back to work, tim ... View more

Well, after expending notable resources with a support request, the result is: #BUG-000137891 On ArcGIS Pro 2.6.3 and above, slowness in display of ‘Properties’ of spatial views is experienced when definition of the query consists of CAST function, CASE function and storage type GEOGRAPHY Which may or may not become available here at some point:  https://support.esri.com/en/Search-Results#search?q=BUG-000137891&content-type=Bugs The technical support analyst determined that removing any one of the CAPS elements above made things speed up. So, it feels like there's a slim chance that a temporary workaround might exist which would require the application of Rube Goldberg design principles.  Maybe splitting into views on views, although query optimizer might hand the same thing to ArcGIS Pro which might continue slowly.  Maybe make a few steps to persist a table that ArcGIS Pro sees?  Idk. cheers & back to work, tim ... View more

Well, not finding an edit button for that post.  2021 has arrived, Sparx EA 15.1 is installed and not up-to-date, and of course stuff has moved around.  Revised instructions: Sparx EA: Start > Preferences > Preferences > Objects > uncheck "Sort Features Alphabetically" Publish > Import > ArcGIS (add the workspace XML, schema only) double-click the "Workspace" object in the project browser to open a graphic view of your geodatabase schema find the disorderly table or feature class graphic right-click within the frame > Features > Attributes right-click the field that you want to be in a different order and choose "Move up" or "Move down" as pleases you Close the Features properties viewer Extensions > ArcGIS > Export ArcGIS Workspace XML Publish > Publish > ArcGIS > specify output XML filename and location > Export ... View more

Hi Alice - In my testing scenario, SQL Server is on a PM - Dell Precision 7530, i9, 32 GB RAM at 2933 MHz, 2 SSDs, which turns out to be pretty zappity and not prone to machinery-borne pokiness.  The Esri support case is still open, and seems to be moving toward bug status this morning after the tech was able to reproduce the problem.  A key finding at the moment is that when I write a view that delivers lat/long columns as SQL Server Spatial geography data type, the slowness occurs with ArcGIS Pro 2.6.3 and up.  All remains fast with ArcGIS Pro 2.6.2 and down and also with ArcMap 10.8.1 and down.  The problem does not currently seem to be about SQL Server, my SQL view writing skillz (which certainly could improve), or the device. cheers, tim ... View more

Update - well...  had to open a support case with Esri.  At present, it appears to be headed toward bug status.  Because a support request can consume significant customer staff time, I can share the case number in case you need to go down this path.  If it reaches bug status, I'll post a link, if possible. ... View more

Hmm.  Well, I just typed up a rather detailed "me too" note on this item which has gone poof.  The short of it is, "me too" with 2.6.3 and 2.7 in SQL Server 2016 eGDB 10.8.1.2.6.  Result - use 2.6.2 and don't spend time with support request. I was stepping back in to add that SQL Server Profiler shows ArcGIS Pro issuing this query: SELECT top 1 SHAPE FROM <view> WHERE SHAPE IS NOT NULL AND SHAPE.STIsValid() = 1 When I issue that query in SSMS, it takes 1m 1s to return one record out of 501 total that the view returns in less than 1s.  SQL Server Profiler indicates that ArcGIS Pro issues the query over and over and over and over again.  Might be a thing to look at. tim edit - it looks like my detailed post de-poofed.  great.   ... View more