Please change: Attribute Table open constitutes a lock for Python Toolboxes

AlfredBaldenweck

Not sure if this is a bug or if it's intentional behavior, but either way I don't remember it being a problem before we switched to Pro 3.1 (our current version).

See this post for further details Pro 3.1.3: Running an update cursor on a feature l... - Esri Community

To summarize, I had a tool I was running involving an update cursor, and it kept failing because of a lock on the data.

It was in a file geodatabase on my own hard drive, so no one else had access.
The data was only used in this project, which was the only project I had open.
I was not in an edit session.

I eventually figured out that having the attribute table open constitutes a lock on the data, at least in the context of a Python Toolbox. Closing the table immediately solved the issue.

The Python Window doesn't seem to be affected, and I have not tested in Notebooks or Scripting tools in an atbx.

Please remove this behavior.

MErikReedAugusta · ‎12-14-2023

I recently ran into a similar issue trying to run a simple da.UpdateCursor operation in the Python window and wondered why it was so lock-happy. I'm pretty sure I also had the attribute table open.

One thing I've noticed after our team switched from Desktop to Pro is that it seems a lot more lock-happy than Desktop was.

RandyCasey · ‎12-14-2023

@AlfredBaldenweck I am surprised you only ran into this issue now, as for years now I have struggled with trying to figure out when and why any GDB gets locked, file or Enterprise. At least with Enterprise GDBs you can disconnect users, if necessary, but not with FGDBs. There should be comparable functionality for all GDBs to disconnect users and release any locks. Especially those random glitch locks that fail to release and stay present indefinitely until the FGDB owner goes in and manually deletes it.

AllenDailey1 · ‎12-14-2023

I wonder if this behavior is because in Pro you don't have to formally open an edit session, you can just click and start editing in the table? so it's like always in edit mode? not sure. Anyway, yes, it would be helpful if it didn't have a lock when you're viewing the table.

ScottFedak2085 · ‎12-14-2023

Do you have the same behavior when viewing the Attribute Table via a TOC object versus an attribute table via a Catalog object. When you view it through Catalog you get that little database silo in the tab and the RightClick menu says "Open Table". When you view it via an object in the TOC the RightClick menu says "Attribute Table". Is it possible the Catalog option accesses the database directly where as the TOC option accesses some sort of cache?

RandyCasey · ‎12-14-2023

@ScottFedak2085 I have experienced this issue when the Details Panel is open in the Catalog View and the Table tab is active, which is why I keep the Details Panel closed by default. I can confirm, with an Enterprise GDB at least, that when the Table tab is active, it is running a Select Query, which is locking that table, so as far as I can tell, any time a table is being viewed, a Select Query is being ran, especially if you are scrolling up or down on that table. I would not be surprised to find out that ArcGIS Pro does the same thing to FGDBs. My question would be: why would you lock the table for just a Select Query when the table isn't even in a state where edits are even possible? to paraphrase @MErikReedAugusta: ArcGIS Pro just seems to lock tables as a default action regardless of context. This is really inefficient and frustrating.

AlfredBaldenweck · ‎12-14-2023

@AllenDailey1 I have manual edit sessions turned on, and I wasn't in one. Also, inside the tool, the cursor is wrapped in an Editor object anyway.

@ScottFedak2085 Just checked, this behavior is still present when opening the table directly from catalog, rather than bringing it into a map. Same thing, closing the table fixes any issues.

Can also confirm @RandyCasey 's issue with running it while viewing the table through the Details of Catalog View. The Geography and Metadata tabs are fine.

PaulPrevedoros1 · ‎12-14-2023

I have found similar behavior using notebook. It appears in doing a calculate on almost 2 mill records, Does not release the lock quick enough before the next action. I solved by adding delays

AlfredBaldenweck · ‎01-02-2024

Another annoying thing along these lines is that, if viewing the file's table in Catalog (even with manual sessions), it'll create a lock file.

Sure, okay.

BUT.

There isn't any way to get rid of this lock file short of closing Pro. Like, could the lock at least be released when I'm no longer looking at that file?

HannesZiegler · ‎01-10-2024

Thank you for your submission. This appears to be a bug. One of my coworkers attempted to reproduce the issue you described but was unable to. Please note that idea Exchanges are not the right place to log software bugs.  However, just because it isn’t the right fit as an Idea does not mean that we aren’t here to help. Bugs and crashes should be logged with Technical Support. Support will help you establish a reproducible workflow that will then help us debug and address the issue.

Note: To contact Technical Support, you need to be an authorized caller. See Why can't I submit cases? (Or, How I became an authorized caller and reported my issue) for more information.

AlfredBaldenweck · ‎01-10-2024

Thanks for the update. Did this get logged as a bug already, or do I need to do that?

In any case, since Pro is so lock-happy, I would not have been surprised had it been an intentional thing.