Latest Contributions by BrianWoodman

I work in a shared Government environment using File GDBs on a network drive. No one has administrative rights to install anything or use programs that require elevated permissions (like PSFile or NET FILE). Some users use ArcPro 2.9.3 while others still use ArcDesktop 10.8. We cannot use QGIS or some other GIS. We do not have the option of installing or maintaining a local SDE. I have Full Windows permissions on a fGDB. I need to replace the contents of a feature class even when other 'Read-Execute' users have it attached in ArcPro or ArcMap/Catalog. As with many before me, file locks on fGDBs are the bane of my GIS existence. The locks can be obvious (a temporary .lock file exists, created by myself, my script or someone else who is using the same data on their machine) OR the locks can be 'HIDDEN'. 'HIDDEN' locks: In ArcPro, when someone else simply VIEWS the feature class on their machine with Catalog, ArcPro DOES NOT create a .lock file, but nevertheless, the file representing the feature class they are viewing, either a .atx or and .gdbtable(?) file, cannot be tampered with, effectively creating the 'HIDDEN' lock. My assumption is that the file has a hidden process handle attached to it from that person's ArcPro exe. Using shutil.rmtree() leaves behind the files it couldn't delete because of the file handle locks, resulting in a corrupted fGDB. Question: Has anyone else observed this behaviour of fGDB files that are 'unaccessible' in ArcPro even though there are no .lock files? Creating a DatabaseView: A way to expose the 'hidden' locks in ArcPro is to first create a DatabaseView from the underlying feature class. These are inherently read-only and created using arcpy.CreateDatabaseView_management(). When the user attaches to the DatabaseView, an .sr.lock file is created. Even with an .sr.lock, we can successfully replace the underlying feature class. This shows great promise BUT, as soon as they open the Attribute table either in their Map or in Catalog using the Table tab, a .rd.lock file is created and we can no longer replace the underlying feature class. This rd.lock makes sense because they are looking at the rows of the underlying feature. Opening the Attribute table in a Map is essential to the user's workflow so we cannot request them to cease and desist from doing that. So, even though we gain the .lock file and the benefit of being able to identify the culprit, this method of creating a DatabaseView in ArcPro DatabaseView fails our purpose. But perhaps the idea of using a different view of the data for the users is not such a bad one. Is there another format besides fGDB that would allow the ArcPro or ArcMap 10.8 user read-only access and yet allow me to replace the underlying data? Could we keep our operational data in fGDB and replace the data of some other format, something that doesn't use .lock files or that mechanism? Could we use something like the file formats afforded by OGC GeoPackage: .sqlite and .gpkg? Replacing a .sqlite file works fine even when an ArcPro user is viewing the data but it fails if a 10.8 user is viewing it. If we can come up with an alternative format for posting the final data, are they compatible with both ArcPro and Desktop 10.8? I would love for ESRI to chime in 🙂 Thanks in advance for your help. Brian ... View more

I asked the Python forum this question (https://community.esri.com/thread/226750-creating-a-python-extension-for-c-in-visualstudio ) but received no response. Perhaps this is a better forum to ask this: In VS2017, I can use the Add-In wizard to create a custom ribbon Add-In using C#; no problem. What I'd like to do is, from within that C# button-click handling code, call different python METHODS (not the python exe). My various methods in python use arcpy so the Python runtime I use needs to be the one that supports arcpy and NOT IronPython. How can I accomplish this?  Thanks in advance for your help, Brian ... View more

I'm developing an AddIn for ArcGISPro. Previously, in my python addin for ArcGIS 10.6, I use a great method to handle code changes on the fly: I use the regular python addin code (let's call it the 'pythonButtonWrapper') to: - import a pythonModule.function code that runs when a particular button is clicked; - 'recompile' that pythonModule code on the fly and; - handle the button clicks, telling the pythonModule code what button was clicked. The pythonModule code then takes over execution. It works great. Because I recompile the pythonModule code on the fly, I can code the functionality into the pythonModule code and never have to touch the pythonButtonWrapper. It never changes (unless of course I add new buttons, etc). ArcGISPro uses Csharp for its addin code and I can generate a 'CsharpButtonWrapper' for it. My question: how can I preserve the same functionality, calling my PYTHON module code functions from the 'CsharpButton Wrapper' that I get with VS 2017, passing in the button clicks? The last thing I want to do is translate all of the python module's code functionality into C#! Note: I've found lots of on-line example code that calls python.exe from C# but that's NOT what I want to do. I need access to the python module functions themselves. Using IronPython in VS can work but then I don't have access to arcpy module calls because IronPython is a different runtime. Thanks in advance for your helpful response, Brian ... View more