arcgis pro geoprocessing tool stuck at 100%

1696
14
Jump to solution
03-24-2020 05:28 AM
PeterMacKenzie2
New Contributor III

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

Reply
0 Kudos
1 Solution

Accepted Solutions
DrewFlater
Esri Contributor

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.

View solution in original post

14 Replies
DanPatterson_Retired
MVP Esteemed Contributor

output featureclass name .... _1

could be an issue

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

RussellBrennan
Esri Contributor

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.

Reply
0 Kudos
JoeBorgione
MVP Esteemed Contributor

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

can't wait to retire....
MichaelVolz
Esteemed Contributor

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

Reply
0 Kudos
DrewFlater
Esri Contributor

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.

View solution in original post

DanPatterson_Retired
MVP Esteemed Contributor

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

Reply
0 Kudos
PeterMacKenzie2
New Contributor III

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. 

Reply
0 Kudos
Tolo__AdamTolo
New Contributor III

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.

Reply
0 Kudos
Tolo__AdamTolo
New Contributor III

The example above finished in 39mins

Reply
0 Kudos