|
POST
|
Hi John, et al, We noticed this problem when we upgraded from ArcGIS Pro 2.6.2 to 2.6.3. It remains a problem at 2.7. We currently have a SQL Server 2016 (13.0.5102.14) database with a view that returns 501 records in less than a second (edit: in SSMS) with ObjectID, Shape (geography, null), and other columns. ArcGIS Pro 2.6.2 could read and load the view in a few seconds. ArcGIS Pro 2.6.3 and up cannot even get the properties for the view in less than 10 minutes. Rather than expending noticeable resources with a support request, our strategy is generally to use ArcGIS Pro "whatever version works" for the particular function that we need to complete. So, in this case, we just read our view with ArcGIS Pro 2.6.2. It would be great if Esri staff could notice this kind of discussion in the forum and handle bug evaluations internally rather than requiring Esri customers to spend significant amounts of our time to reproduce and enter into the bug log. It would be even greater if all the testing harnesses and holistic quality approaches could catch these sorts of things. tim
... View more
01-05-2021
08:06 AM
|
1
|
0
|
5391
|
|
POST
|
Ok, I got back around to it. I made a backup of an example database in my sandbox environment, then followed the guidance in the linked SQL Server documentation above to shrink it. It dropped from ~188 GB to ~10 GB instantly. It's a 10.8.1.2.6 enterprise geodatabase schema, so I added all content to an ArcGIS Pro 2.6.3 map and rendered it. Some spot checks suggest it's working fine. I did not get into any deeper testing that might reveal subtle problems, but I kind of don't expect any. Cheers, tim, OCIII
... View more
12-21-2020
02:11 PM
|
1
|
1
|
3433
|
|
IDEA
|
If the FBThumb / Kudo thingy is the new "vote this idea up" thingy, then I'm voting up... or thumbing or something. Yes, please consider making it easy to export, delete, overwrite, edit, view, and redact confidential system information from metadata for all objects that support metadata. Edit - a little while later... it turns out there is a Rube Goldberg (https://en.wikipedia.org/wiki/Rube_Goldberg_machine) approach to doing this. Posting it here so I can find it again when the need arises. ArcGIS Pro > Project > Options > Geoprocessing > uncheck "Write geoprocessing operations to dataset metadata" make a new feature class and import the fields from your original feature class, being sure to define the coordinate reference system the same. Use the Append GP tool to load the records from your original feature class to your new feature class. You turned off geoprocessing metadata logging, so it won't record in the metadata, hopefully. View the metadata for the original feature class, then "save as XML" (don't be tempted to export) like this: I can't always reproduce the steps to get to that control. Sometimes it appears, sometimes it doesn't. Might be another idea... anyway, import that metadata to your new feature class. Confirm that it all worked as you hoped. Done. Whew. tim, Occasional Contributor III (my new Esri volunteer job title)
... View more
12-11-2020
02:57 PM
|
0
|
0
|
1564
|
|
POST
|
Hi Lisa, Nope, no progress. I got all tangled up in COVID-19 support for our agency, and am only fully back to my day job now. Actually, this item dropped through the cracks, and I need to get back around to it. I think I have some kind of trashy databases lying around that I can test on without concern. Thanks for the reminder . I'll post my results here when I have some. tim
... View more
09-04-2020
03:46 PM
|
0
|
0
|
3469
|
|
IDEA
|
ArcGIS Pro 2.4.x geoprocessing tools have a "View Details" function which explains what it's doing pretty well. This is useful for observing ModelBuilder's progress and troubleshooting. ArcGIS Pro 2.5.x and beyond clammed up. "View Details" does not provide details anymore. So, ArcGIS Pro should still talk to the humans when we want to hear it. It should clam up when we tell it we don't want to hear it. Esri could get fairly fancy and provide the user with control over how quiet or how noisy it should be. See ArcGIS Server logging for categories. That's my idea, tim
... View more
08-06-2020
11:38 AM
|
4
|
0
|
627
|
|
IDEA
|
Hi Kory Kramer I agree. Please change the title to "ArcGIS Pro could maintain layer field order and alias when sharing web layer with time zone specified" if it has any chance of fitting and reset the status. I don't think it's a niche idea. I also think it fits squarely within the "Esri could provide an integrated, consistent, and reasonably good quality ArcGIS Platform" idea. Thanks, tim
... View more
04-28-2020
03:58 PM
|
0
|
0
|
3954
|
|
POST
|
I agree. Thumb this up if you're willing - https://community.esri.com/ideas/17706
... View more
04-28-2020
03:47 PM
|
1
|
1
|
3956
|
|
IDEA
|
Not in context of the ArcGIS Pro "Enable Editor Tracking" or ArcGIS Enterprise "Keep track of who created and last edited features" capabilities. The field could have been named "TimTestDate" and my hypothesis is that it would have been shoved to the back of the list and renamed "timtestdate". The same thing happens when using the Convert Time Zone GP tool, so I hypothesize that the "share as web layer" function calls the GP tool, uses its code, or is similar in some other way.
... View more
04-23-2020
10:09 AM
|
0
|
1
|
3954
|
|
IDEA
|
Hi Kory, Well, bummer. Nope, my idea remains quite valid in my opinion. I found an ArcGIS Enterprise 8 environment that I could test with. Getting into a little computer science here... hypothesis: Kory is right and Tim is wrong test: using WA-DNR's county boundaries (WA County Boundaries ) as the source feature class, import it to an ArcGIS Pro 2.5 file geodatabase, then share as web layer to an ArcGIS Enterprise 8 deployment. Check the position and name of the date column before and after. If the position and name of the date column has changed, then the hypothesis is disproven. results: hypothesis is disproven
... View more
04-23-2020
09:27 AM
|
0
|
1
|
3954
|
|
IDEA
|
Hi Kory, How do we reset this idea to "not offered"? Clue in bold italics... ArcGIS Pro 2.4.3 changes the field order when I "Share as Web Layer" and "Overwrite Web Layer" to an ArcGIS Enterprise 10.7.1 hosted feature layer. Mostly, the end result are date fields ordered at the tail end of the field list with the field aliases stripped off. This is truly annoying and causes duplicate work to monkey around with the pop-up field order and aliases. I upgraded to ArcGIS Pro 2.5, immediately smacked my head on this (BUG-000129031: In ArcGIS Pro 2.5, publishing a hosted feature layer.. ), used "language" out loud, and observed that ArcGIS Pro 2.5 continues to change field order for me when I don't want it to, and refuses to change field order for me when I do want it to (ArcGIS should allow the ability to permanently reorder fields in a table). How to reproduce: make a file geodatabase feature class add a date column somewhere in the front of the column list share as web layer > Feature Layer > copy source data to AGE specify the time zone and daylight savings time publish to ArcGIS Enterprise 10.7.1. Ta-dah, ArcGIS Pro mangles the field order, alias, and column name. I notice that the Convert Time Zone GP tool offers the same results, so that's probably a clue for whoever didn't get the design principle message that ArcGIS does not change field order. Cheers, tim
... View more
04-22-2020
01:22 PM
|
0
|
1
|
3954
|
|
IDEA
|
ArcGIS Pro 2.4.3 changes the field order when I "Share as Web Layer" and "Overwrite Web Layer" to an ArcGIS Enterprise 10.7.1 hosted feature layer. Mostly, the end result are date fields ordered at the tail end of the field list with the field aliases stripped off. This is truly annoying and causes duplicate work to monkey around with the pop-up field order and aliases. As a general expectation, I want the entire ArcGIS web service publishing results to respect all of the configurations I make in the: source geodatabase field definitions, order, metadata, etc. ArcGIS Pro map and layers publishing configuration - e.g. if I set the time zone and daylight savings time, don't make me reset it every time I overwrite the service. I believe I've had an idea about this kind of thing before. Where's the link to that satisfaction survey? tim
... View more
04-15-2020
09:42 AM
|
2
|
9
|
4146
|
|
POST
|
I'm getting charged per GB for SQL Server storage, so I have an incentive to use just as much storage as I need and no more. There are enough GB involved to create an attractive benefit to using less storage. I immediately think, "shrink the database." Then I think, "uh oh." I notice that the Esri help is silent on the subject: ArcGIS Pro: Enterprise geodatabase maintenance tasks—Manage geodatabases in SQL Server | Documentation ArcMap: Geodatabase maintenance—Help | ArcGIS Desktop While the Microsoft help is not: SQL Server 2016: Shrink a Database - SQL Server | Microsoft Docs So... have you ever done this successfully with an enterprise geodatabase in SQL Server? Any gotchas, hints, suggestions, soothing sounds, pointing and laughing? Thanks, tim
... View more
02-06-2020
03:17 PM
|
0
|
17
|
5366
|
|
IDEA
|
When publishing and overwriting map services from ArcGIS Pro to ArcGIS Enterprise and/or ArcGIS Online, the user could have a radio button to "Add and update features only". Alternatively, change the radio buttons into check boxes like in the ArcGIS Server Manager settings. This would support requirements where app users are only allowed to add and update features. The present workaround is circuitous, laborious, and spattered among various configuration settings. tim
... View more
01-07-2020
09:28 AM
|
2
|
3
|
4365
|
|
POST
|
I've had this problem for some time now, too. I'm just assuming it's another bug and moving on. Don't believe the red x! tim
... View more
12-13-2019
11:59 AM
|
0
|
0
|
3418
|
|
IDEA
|
ArcGIS Pro UI dialogs could provide a bug status indicator to give a user an idea of the road ahead. No UI dialog symbol: good to go. The happy path presented in the help documentation has not been shadowed by the wings of bugs as far as Esri is aware. Yellow “yield/exclamation mark” UI dialog symbol: click to bring up a listing* of bugs with established workarounds. Review the bugs and the workarounds that sound like they affect what you want to accomplish. Red “stop/x mark”: click to bring up a listing* of bugs with no established workarounds. Review the bugs that sound like they affect what you want to accomplish. Determine alternate path to success. *Each bug listing entry includes an “I need this to work” button for the user to click to register their desire to have Esri make the product do what it says it does. This can be used by Esri for prioritization. Also, if the user is signed in to something Esri (ArcGIS Online, GeoNet, my.esri.com, etc.), they get access to the “internal” bug listing as well as the external bug listing, if such dichotomy exists. It seems that most, if not all of the components to support this idea are available. Just a matter of linking up UI elements to the big box of uniquely identified and documented bugs. Existing symbols from the GP tools parameter field status indicator could be re-used as the UI dialog symbol. Yellow and / or red could be on at the same time. Maybe go so far as to integrate the bug reporting process into the UI dialogs where the user can initiate a bug report at the point of suspected failure, let ArcGIS Pro gather its logs, let the user edit the log and submit it for support to review. Benefits: ArcGIS Pro users have the information they need to meet their objectives, either along the happy path or along the less happy, but successful path. Big time saver for customers to have their expectations set early about using specific ArcGIS Pro functions. Clear information about situations so customers don’t blow time and money by spiraling down into troubleshooting. Clear picture of ArcGIS Pro quality levels to everyone involved. After some time and focus on quality, higher quality software and happier customers. Costs: Full testing. You wouldn’t want your bug status indicator subsystem to be full of bugs. Added capability to ArcGIS Pro – product manager, architect, developer, tester, etc. Risks: Clear picture of ArcGIS Pro quality levels to everyone involved. Mitigation: fix the bugs and get rid of the yellow and reds = happier customers More complexity. Example - Ok, so I need to get some geo-work done. I haven’t used these particular tools in ArcGIS Pro yet, so I go read the help, follow the guidance, click the “OK” button, and… not ok. Try again, investigate, research, fail, mess with GeoNet, spend time not getting any geo-work done. Example: Related discussions and ideas for integration: https://community.esri.com/ideas/17722-streamline-bug-reporting https://community.esri.com/thread/245046-arcgis-pro-bug-reporting-wo-the-hassle https://community.esri.com/message/610584 and many more, probably, but I'm not digging them up. tim
... View more
12-11-2019
11:14 AM
|
3
|
1
|
867
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 10-24-2024 02:51 PM | |
| 1 | 10-24-2024 02:39 PM | |
| 1 | 10-22-2024 02:31 PM | |
| 1 | 02-07-2024 09:16 AM | |
| 1 | 02-07-2024 08:11 AM |