Is ArcMap 10.1 64-bit background geoprocessing compatible with ArcGIS Server 10.1?

3507
13
Jump to solution
05-09-2013 09:39 AM
AlanStewart
Occasional Contributor
I have both installed on the same box. There are DTBGGP64.pth and a Server10.1.pth files in the C:\Python27\ArcGISx6410.1\Lib\site-packages folder. The first points to the the C:\Program Files (x86)\ArcGIS\Desktop10.1\bin64 folder and the second points to the C:\Program Files\ArcGIS\Server\bin folder. This seems to be a conflict.

When I enable background processing and debug into a Python geoprocessing task it fails when arcpy is imported. Printing sys.path reveals:

>>> sys.path: ['C:\\ARCGIS~1\\GEOPRO~1\\TGT_GP~1\\Scripts', 'C:\\ARCGIS~1\\GEOPRO~1\\TGT_GP~1\\Scripts', 'c:\\program files (x86)\\arcgis\\desktop10.1\\bin', 'c:\\program files (x86)\\arcgis\\desktop10.1\\ArcPy', 'c:\\program files (x86)\\arcgis\\desktop10.1\\ArcToolbox\\Scripts', 'C:\\arcgisserver\\geoprocessing\\TGT_GPExporter\\ExportGeoPDF.tbx', 'C:\\Windows\\system32\\python27.zip', 'C:\\Python27\\ARCGIS~1.1\\DLLs', 'C:\\Python27\\ARCGIS~1.1\\lib', 'C:\\Python27\\ARCGIS~1.1\\lib\\plat-win', 'C:\\Python27\\ARCGIS~1.1\\lib\\lib-tk', 'C:\\Python27\\ARCGIS~1.1\\Lib\\SITE-P~1\\PYTHON~1', 'C:\\Python27\\ARCGIS~1.1', 'C:\\Python27\\ARCGIS~1.1\\lib\\site-packages', 'C:\\Program Files (x86)\\ArcGIS\\Desktop10.1\\bin64', 'C:\\Python27\\ARCGIS~1.1\\lib\\site-packages\\win32', 'C:\\Python27\\ARCGIS~1.1\\lib\\site-packages\\win32\\lib', 'C:\\Python27\\ARCGIS~1.1\\lib\\site-packages\\Pythonwin', 'C:\\Program Files\\ArcGIS\\Server\\bin', 'C:\\Program Files\\ArcGIS\\Server\\arcpy', 'C:\\Program Files\\ArcGIS\\Server\\ArcToolbox\\Scripts']

Note that it is pointing to the 32-bit Desktop bin folder, before the 64-bit Desktop bin64 folder is pointed to. Where is all these extra path entries coming from?

I need to publish the geoprocessing task to Server. In the past we have used ArcMap on the Server box in authoring our web applications, which call a geoprocessing task. Is this not possible anymore?
0 Kudos
13 Replies
AlanStewart
Occasional Contributor
It has miraculously started working. I did nothing other than update the legacy "import arcgisscripting... arcgisscripting.create()" to "import arcpy" and rearranging some of the embedded debugging messages.
0 Kudos
AlanStewart
Occasional Contributor
I may have this figured out. For me the breakage seems to only happen when using the 64-bit version of PythonWin and only when ArcMap opens PythonWin. I.e., Pythonwin is closed when the debug session is started from ArcMap.
0 Kudos
AlanStewart
Occasional Contributor
ESRI tells me the issue also occurs when ArcMap is set to use 64-bit PythonWin as the Python editor. NIM091620 has been created to address the issue.
0 Kudos
KevinHibma
Esri Regular Contributor
Based on the information your presented here and the bug that was logged, we now know its because of the path and its contents when you launch an IDE from ArcMap (right click on script > edit for example).
If you launch the IDE by itself, the path is fine.
When launched from ArcMap you'll see the 32bit path in the sys.path: c:\\program files (x86)\\arcgis\\desktop10.1\\bin

As a hack, you could do this:
import sys
sys.path.remove('c:\\program files (x86)\\arcgis\\desktop10.1\\bin')
import arcpy
#rest of your script


Or if you're using an IDE that you set the Python interrupter, like WING for example, you can qualify which Python it should run against (like the 32bit one)
Or using a 32bit IDE will work fine as well.
0 Kudos