Latest Contributions by ZacharyHart

Joshua Bixby‌ Dan Patterson‌ Darren Wiens‌ Hi everyone, I wanted to thank you for your help and also give you a bit of an update. Here's what I know to date: Today Esri Support verified there was a bug for this tool. BUG ID: BUG-000117445 Synopsis: The Save To Layer File management tool fails and returns Error 999999 when run from the Python IDLE window in ArcGIS Pro. Status: New We confirmed that this tool also fails when used in a script tool The current ArcGIS Pro documentation is still outdated and referencing working with .lyr files. I was able to find a workaround using 'saveACopy' as part of the arcpy mapping module layer class. Here is a quick example: #Import Modules import arcpy, os #Variables Date = time.strftime("%m%d%Y") OutputFolder = "D:\\TEMP" LayerName = "SoilsMUID_" + Date + ".lyrx" ExportLayer = os.path.join(OutputFolder, LayerName) #Setup Map Document Info aprx = arcpy.mp.ArcGISProject("Path to your aprx file") map = aprx.listMaps("Soils")[0] SoilsLyr = map.listLayers('SoilsMUID')[0] ##This layer's data source is a shapefile #Export Layer File arcpy.AddMessage("Exporting Layer File to {0}".format(ExportLayer)) SoilsLyr.saveACopy(ExportLayer)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Joshua Bixby‌ this is very helpful from a diagnostic perspective. Thanks a bunch! ... View more

Dan Patterson‌ Dan, that makes perfect sense! So, now I'm wondering why (regardless of the script tool) the tool works one way but not the other in Pro? I don't know if that's a bug or hints at one, or possibly that there is indeed something wrong with the inputs since arcpy.management.SaveToLayerFile Returns a 000622 error. Also, I failed to answer one of Dan's original questions which was if the map project was open. When I run the code from the python window setting the aprx to 'CURRENT' it works fine. However...when I run the code in the python window from another map  project and set the aprx to the full file path of the closed project, then I get the same error as in my script tool! So that's something there. ... View more

Dan Patterson‌ I didn't expect this thread to morph like this so I should probably rename the title. I'm still curious what the difference between arcpy.mangement.{tool} vs arcpy.{tool}_management ... View more

I like your thinking in eliminating that, but that also failed with a 999999 error (Curiously, looking up a 999999 error I expected it to say "This is the most informative error code ever!"...sadly it did not). ... View more

Dan, I didn't expect that it will return a full path for a file on disk since I'm using the listLayers method for a layer within the map. I modified the message per your request and got the following from the script tool.   Again, if we comment out the SaveToLayerFile the script goes on to use SoilsLyr for several other things just fine so it sure seems the script has access to that as an input just fine? arcpy.SelectLayerByAttribute_management(SoilsLyr, "NEW_SELECTION") mf.zoomToAllLayers(True,True) arcpy.SelectLayerByAttribute_management(SoilsLyr, "CLEAR_SELECTION") mf.camera.setExtent(mf.getLayerExtent(SoilsLyr,True, True))‍‍‍‍ ... View more

Ah, yes...important clarifications. Sorry if i wasn't specific enough...I thought Esri was calling the 'python window' the built-in interface...well, at least that's what they called it in ArcMap. But yes: built-in interface in ArcGIS Pro...no console. 2 separate issues but I'll focus on your questions first. If I run the the code from the 'python window' the layer file is exported just fine...within the script tool it fails with a 999999 error. One thing to keep in mind here is that these inputs are used elsewhere in the script tool just fine. But let me try to pare this down to what's relevant here. #Import Modules import arcpy, os #Variables Date = time.strftime("%m%d%Y") OutputFolder = "D:\\TEMP" ##In the script tool this is exposed as a parameter and not hard-coded. LayerName = "SoilsMUID_" + Date + ".lyrx" ExportLayer = os.path.join(OutputFolder, LayerName) #Setup Map Document Info aprx = arcpy.mp.ArcGISProject("CURRENT") ##In the script tool, this points to an aprx file using the full path. map = aprx.listMaps("Soils")[0] SoilsLyr = map.listLayers('SoilsMUID')[0] ##This layer's data source is a shapefile #Export Layer File arcpy.AddMessage("Exporting Layer File to {0}".format(ExportLayer)) arcpy.SaveToLayerFile_management(SoilsLyr, ExportLayer)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ In the script tool (if the SaveToLayerFile is commented out), the tool goes on to select the in_layer, zoom to it, and some other stuff and then a PDF is exported no problem. FWIW, I also tried to create a feature layer from SoilsLyr and then pass that to SaveToLayerFile_management (unneeded but worth a try) and that fails as well. ... View more

This is helpful, thanks! ... View more

This is helpful, thanks! ... View more

I'll try to clarify: The local SQL Express/ArcGIS Workgroup instance is only there to support local multi-user editing for our core GIS staff. This is a DB replica. The parent of this replica resides in SQL Standard/ArcGIS Enterprise in Azure. From Azure is where our feature & map services will be created/hosted. Does that help explain things better? Again, if you do not have the need for multi user editing, the following are potential options you could use in order to still support local editing but have your eGDB reside in Azure: ArcGIS (Desktop) Database Server ; in this scenario you could still have a 2-way replica with your local copy/replica sitting on SQL Express. Check-out a local copy from your eGDB as you need it. If you're doing this often and/or have to sync your changes often you'd grow tired of this quick. Depending on the gradient of editing needs from your user base, you may be able to offload some or most of your editing to feature services This may help illustrate a few different scenarios you could implement. ... View more

Collin Johnston‌ Johanna Kraus‌ Lourdes Suman‌ UPDATEish: Lots of testing has been done and we're now moving forward with implementation. To be clear: We're not using Azure SQL (Paas) but are instead migrating all of our company DB resources ( currently in a datacenter and this is not just GIS) to an SQL Server instance (on a VM) in Azure (IaaS), and our (current) onprem SQL Standard instance which hosts our eGDB is along for the ride. We will have a separate VM hosting ArcGIS Server federated with ArcGIS Portal (so Base ArcGIS Enterprise Deployment). Previous testing related to eGDB issues revealed the following: 'Local' access of the eGDB/RDBMS over-the-wire to Azure was simply too slow. An eGDB/RDBMS accessed by ArcGIS Enterprise and hosting services all in Azure worked great and services are easily consumed via the web. The only viable solution here in order to continue to support multi-user editing on-prem is to stand-up an ArcGIS Workgroup instance (this sits on SQL Express)**. We will then use a 2-way DB replica to sync changes between the two environments.  Now, if you want to talk about handling file data...that's a whole other can of worms.... **If you do not need to support multi-user editing ArcGIS (Desktop) Database Server may have some value to you. ***EDITED: Lots of points of clarity. Happy to provide more details. ... View more