Provide the ability to run integrated ArcPy 3.6 operations from database IDEs using tools such as XP_CmdShell. You can do this with ArcPy 2.7, can't do this with ArcPy 3.6.
Can you provide some additional context on what you'd like to accomplish? I'm not familiar with XP_CmdShell and how ArcPy is used in conjunction with a database IDE.
In SQL Server Management Studio SSMS, we run our store procedures nightly that take several horus to run. Integrated between SQL and ArcPy as integrated processes.
.ArcPy 2.7 has worked for years. EXEC xp_cmdshell 'C:\Python27\ArcGISx6410.8\python.exe F:\CIA_Python\PROD\PythonScripts\VMS_OBS_COMBINE_LINES.py';
-- This ArcPy 3.6 which does not work with XPCmdShell because it throws licensing issues with or without ArcPro open. This box also has ArcGIS Enterprise installed.
def print_profile_info(gis): print("Successfully logged into '{}' via the '{}' user".format( gis.properties.portalHostname, gis.properties.user.username))
@SteveLewis Thanks for providing some additional context. It looks like this issue may be specific to your environment and require some debugging to determine the nature of the problem. Can you log a support ticket for this case? In the samples given the Python 2.7 environment is running against the Server installation, where the Python 3 environment is running against Pro. It may be that these are licensed differently, or it may be that xp_cmdshell launches these processes as a different user than the authenticated user, and the job needs to be set up to reflect the need to authenticate as the running Pro user. I did install SQL Server Management Studio SSMS, but didn't see anything related to xp_cmdshell built into that package, so imagine there are additional steps to recreate the specific configuration being used, and support is the best avenue to try and tease out where the licensing issue is being hit.
@MichaelRaasch could you log a case with support on this issue? We don't yet have a reproducible case for this issue and working through technical support will allow us to ensure we have the same workflow locally and understand any potential configuration issues that may be present. If we identify a specific issue with SSMS, it may be on our side, on Microsoft's side, or a configuration setting that can be handled.
@ShaunWalbridge we are currently working with Rob Haley from ESRI regarding this issue and he mentioned this community article...so I was just following up to see if @SteveLewis or ESRI had a resolution for this issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
