Scripts works on PC but not server running same python versions...why?

[LindsayRaabe_FPCWA]

I have a python script that takes an ArcGIS Online feature service and uses it as an input in an arcpy Dissolve process. I built it (and ran it successfully) on my PC which was running ArcGIS Pro 3.1 but found it wouldn't work on our server which was still running 2.9.5. I put this down to advancements in the capabilities at the 3.0 upgrade and relevant python packages.

However, we recently upgraded our server to 3.1 as well and when I tried running this script on there, it fails complaining about the parameters (fails at the step where it tries to dissolve a feature service). Why would this be when all the software is supposedly the same?

 

Also, other script that were running on the server have now inexplicably stopped working. No error codes, they just stop. Why?????

  

[BlakeTerhune]

Is this a DMZ server? Maybe you need to open some firewall ports for the server to access that url. As for the other scripts just "stopping", do you have try/except blocks? What are you doing when you catch an Exception?

[LindsayRaabe_FPCWA]

I'm not across the different server types. We ended up bringing forward the spin-up of a new server with clean installs and running a modern OS. The one used above was nearly a decade old and full of rubbish. The new server ran much cleaner, though the URL input parameter was still a problem. 

I ended up finding a work around (or maybe "better") solution for the ArcGIS Online source data that did work without having to change anything else (which leads me to think the firewall wasn't an issue). 

Instead of using the URL as the input parameter in the tool, I used it as the input parameter for the below code, then passed the local_fs parameter to the geoprocessing step. 

print ("Export ArcGIS Online layer to feature class")

infc_nf = #"ArcGIS Online Feature Service URL here"
proc_gdb = #"path to GDB" 

import arcgis.features
from arcgis.features import FeatureLayer
fl = FeatureLayer(infc_nf)
fs = fl.query()
local_fs = fs.save(proc_gdb, "local_fs")

print ("Dissolve layer")
diss_nf = arcpy.management.Dissolve(local_fs, proc_gdb + "\\dissolve_nf", "Field1", "", "MULTI_PART")

[DarylHochhalter]

I'm having the exact same issue with the same version of python. Server 11.1 script gives error

Error Info:
Failed to execute. Parameters are not valid.
ERROR 000732: Input Table: Dataset A:\ArcGIS\DixTools\Connections\CamaVision64.odc\GENERAL does not exist or is not supported

Very same same script on Pro desktop machine successfully runs. Running from IDLE Python 3.9.16 [MSC v.1931 64 bit (AMD64)] on win32 I am connected to the server via remote desktop?

[LindsayRaabe_FPCWA]

Sorry I can't offer any advice. I just worked on it until I found a workaround that in the script that worked. I think the other factor in my situation was a server migration to newer infrastructure which let the script run. Been a while now so the details are foggy. Still very frustrating though how everything is same-same but inexplicably different. 

[DarylHochhalter]

I found out late yesterday that the issue in my script is that it can't seem to connect through the .odc file to an external database. The frustrating thing is that I can connect to the database if I go through Pro from my desktop using the very same file from the same location. Also, going into the ODBC connection directly on the server machine the test connection works. I'm guessing that some of the required windows features for enterprise 11.1 changed something related to those connections, because all other parts of the arcpy script run fine from the server machine. But don't know what that issue might be???

[LindsayRaabe_FPCWA]

I've just remembered another detail that "may" help. I've been using a mix of arcpy and arcgis modules and I can't recall which it is, but one uses my ArcGIS Pro login credentials to ArcGIS Online to access our AGOL environment. When running stuff on my PC, it would work (even with ArcGIS Pro closed) because ArcGIS Pro still had a valid connection to the environment. On the server though, I had not logged in (or had used a different account) thus the python module couldn't access the environment. It's a bit annoying, but I need to ensure periodically that ArcGIS Pro has been opened on the server using the same Windows login that triggers the python script in Scheduled Tasks and then that ArcGIS Pro is logged in to ArcGIS Online using the correct AGOL account. 

Maybe it's something similar with the ODBC connection?

[DarylHochhalter]

I know what you're talking about, but that isn't the case with the regular arcpy import, which is all this script uses. Also, it was running on the server prior to the update to 11.1 from 11.0. The arcgis pro conda environments are actually identical on both machines now, at least according to the version, but apparently not by functionality. As for importing the ArcGIS module to a python script, it is easier when you can use the Pro credentials to initiate GIS, but I don't even have Pro installed on the server machine. You can get around that by entering the credentials in the script or supposedly somehow using the a windows keyring profile, but none of those work arounds are efficient especially is you want to run it as a task. 

My issue seems to be that arcpy no longer recognizes a .odc file as a workspace connection file, like it does with an sde file. The actual ODBC DNS in Windows is valid and I can open the connection using pyodbc. Also, Arcpy can access the .odc file, but just doesn't see it as a workspace, it describes it as a file not a remote DB. Even when I run that script from my desktop it is accessing the very same .odc connection file and working, it's very weird.

[LindsayRaabe_FPCWA]

Regarding the login options you mentioned, I'm not permitted to store credentials in script (cyber security rules - I used to do it this way and it was a lot easier) so now I do use Keyring to manage credentials in most cases. I just haven't worked it out in all instances (that's where my lack of knowledge around the different modules as kept me back).