nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

arcgis pro geoprocessing tool stuck at 100%

PeterMacKenzie2

I am using the copy features geoprocessing tool. Copying a hosted feature layer to a local fgdb, with attachments so it should churn for a while but....
The progress bar jumps to 100% quite fast but then just sits there. See screenshot. It's been at 100% for 20 mins.

What is happening here?

ArcGIS Pro 2.5
arcpy.env.maintainAttachments = False
arcpy.env.autoCommit = 500

geoprocessing tool progress bar at 100%for 20 mins

Najděte více příspěvků označených jako

Accepted answers

DrewFlater

Peter MacKenzie‌ did you set the environment in the Python window via arcpy.env.maintainAttachments = False, and then run the tool through the Geoprocessing pane UI? Once the project environments are established, changing the arcpy.env does not impact the environment settings for your project or the tools run in the Geoprocessing pane UI. You can think about it as a one way street - the environments set in the project are automatically derived into arcpy.env, but changes in arcpy.env don't flow up to the project environments.

This could be a reason why the tool is stuck at 100% for a long time - the maintain attachments setting never got disabled for tools run in the Geoprocessing pane UI. Transferring attachments is a post process of creating new relationship classes and transferring potentially large amounts of binary information in blob fields into a new table in the geodatabase. The progress bar accounts for the feature transfer, but not for the attachment transfer which is a much less deterministic process, as each attachment can be a different size and require more or less processing time.

Dan Patterson‌ had a hunch about that output named g.gdb\_1 -- the geodatabase does allow this name, and I could successfully run CopyFeatures with an output named _1.

Russell Brennan‌'s suggestion about Fiddler would help to debug if queries are still being made to the service or if things are stuck on the client side for a long period of time. Working with Esri Tech Support would help to do some of this troubleshooting for you.

All comments

DanPatterson_Retired

output featureclass name .... _1

could be an issue

Reboot, rename and try again rather than waiting might be a solution

RussellBrennan

Do you have Fiddler installed on your machine? This could tell you if query requests are being submitted from Pro and it's just slow or if Pro has hung.

JoeBorgione

I've experienced similar and erratic behavior with a variety of tools since upgrading to 2.5. Mostly what I see is the process hangs at 4% for what seems like forever, and all of the sudden will jump to 75% and hang there for a while. I thought it might be due to the fact that I have fgdb's on shared drives. However I see the same erratic behavior when the data is local on my C: drive.

See https://community.esri.com/thread/248828-running-a-tool-in-arcgis-pro-25 complete with gifs....

Russell Brennan‌

MikeVolz

Have you bern running any models in Pro? If so, do you see any erratic behavior in that environment?

DrewFlater

Dan Patterson‌ had a hunch about that output named g.gdb\_1 -- the geodatabase does allow this name, and I could successfully run CopyFeatures with an output named _1.

DanPatterson_Retired

Drew Flater‌ that leaves ... Reboot, retry ... before Tech Support

PeterMacKenzie2

Sorry, my mistake. That was actually arcpy.env.maintainAttachments = True as I was needing to maintain attachments. I think you might be right Drew Flater‌, it had a significant amount of attachments so the progress wasn't really a good indicator of thus, I have fiddler but need to work out how to use it next.

Tolo__AdamTolo

I have also ran into this issue using various geoprocessing tools in Pro 2.5

When using the "Delete Rows" geoprocessing tool, it gets to 100% fairly fast (lets say 5 mins) and then is stuck trying to complete

I have also tried using the "Feature Class to Geodatabase" tool with the same issue except that it gets stuck at 4% and sometimes it randomly completes after a certain length period and other times it does not.

The data that I am running these tools on, are in a postgresql database.

Will push this onto Tech Support, I have a feeling it is an issue with the specs of the machine.

Tolo__AdamTolo

The example above finished in 39mins

MarcoBoeringa

You really should open up pgAdmin, the database manager tool of PostgreSQL, to truly see what is going on. E.g., if you deleted only a selection of the rows of a (very) large table, and the Delete Row tool triggers a VACUUM FULL on your table, then PostgreSQL may have spend the excess 34 minutes re-writing the entire table in the background to remove dead tuples / rows and optimize the table by re-claiming disk space.

Some database operations are inherently costly, and may not show progress (although it would be a good thing if geoprocessing tools in applicable cases and where possible showed at least a warning message if such situations are occurring).

Note that in case you intend to delete all rows of a table, the Help justly recommends using the Truncate Table tool instead, which will be must faster / instantaneous.

Tolo__AdamTolo

I have been in pgAdmin for other tasks today but how do you see the status of a running tool and what it is triggering?

Appreciate the information about Help and the Truncate Table tool too!

MarcoBoeringa

Hi Adam,

Note that you will not see the actual geoprocessing tool listed in pgAdmin. Instead, the ArcSDE application is what handles the SQL communication in the background with PostgreSQL.

To access that information in pgAdmin:

- Click on the database in the left pane

- Click on the Dashboard TAB in the right pane if it isn't already visible

- In the Server activity pane on the bottom, choose Sessions if it isn't active

- In the displayed list of sessions, look for your user name and / or IP address in the User / Client columns and a session with "ArcSDE" in the Application column.

- Check that the State is active. In the example below, only the postgres user has an active status, but this was just an example screenshot. Idle sessions should be ignored, they are no longer active.

- Click on the little black arrow in the third column of the display of an active session to open a drop down that shows the Details of the active session.

- You can now see the SQL being executed at this moment.

Note that the Server activity details pane is not automatically refreshed, use the refresh button in the top right of the details pane to update it.

It is easiest to do all of this on a database not used by hundreds of other users, as you will immediately see the proper user / IP address, instead of potentially hundreds of sessions in the Server activity pane.

pgAdmin,ArcSDE

StephH

Hello, I am experiencing the same issue when trying to create a space time cube from a multidimensional raster layer using the geoprocessing tool. How is this issue resolved? Thank you!

Sharon_Low

I tried to execute raster to point using dem 250m as input raster and it got stuck at 100% for a long time - more than an hour. I aborted and tried again a few times and also didnt work out. I have also tried the solution proposed here - set the environment in the Python window via arcpy.env.maintainAttachments = False, and then run the tool through the Geoprocessing pane again.... it still didnt work.... any other suggestion is welcome.

Sharon_Low

just a note to say that the input values are integer and not values

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.