Bug with "Database Connection" in Python using 10.1

859
12
Jump to solution
02-01-2013 11:15 AM
GregoryDillon
New Contributor III
I just installed 10.1 on my PC.   Now when I run my Python script it no longer recognizes any connection coded like "Database Connection\Connection to ...".    These connections work in ArcMap and ArcCatalog.   When I create a Model using these connections, the model works.   When I export the Model to a Python script the model it fails.    If I replace the "Database Connections\..." path prefix with something like "C:\Users\SomeUser\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog\..." it works.   In short Python is not resolving "Database Connections" to the actual location of the connections (ie. "C:\Users\SomeUser\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog").   I have SP1 installed on the ArcGIS 10.1 for Desktop.    My C: drive has both a "Python26" and a "Python27" directory.   Maybe its getting confused where to run Python?    Also it looks like ArcCatalog/ArcMap run as 32 bit where as Python runs as 64-bit.   Is there something I can do to configure the 64-bit side to find "Database Connections".   

Please help!   Thanks!
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
ChrisFox3
Occasional Contributor III
I can see the arguement for logging an enhancement when exporting a model to a python script using the "Database Connections" keyword in the path that we automatically write out the full path to the connection file instead of using just Database Connections.

However targeting the wrong version of python when executing your scripts is the much bigger issue here. You would see the same problem if your script tried to process a personal geodatabase feature class, because PGDB is not supported with ArcGIS Server, or if you tried to use some of the metadata tools because they are not supported in Server. We can't do anything about this when exporting the python script because a python script itself cannot explicitly target a version of python to run against at python 2.7. Here is a python bug that describes this limitation and the ultimate solution at Python 3.3.

http://bugs.python.org/issue4485

This all comes back to file associations. If you installed ArcGIS Desktop first and then installed ArcGIS Server, the file associations for a .py file would be set to the 64 bit version of python 2.7 or the last version of python installed, so if I double-click to the script it would execute against Python 2.7 64 bit. Let's say I then installed stand-alone Python 3.0, then the file associations for .py would be set to Python 3.0 and if I double-clicked to run my script it would fail when importing arcpy. You can modify the file associations of .py files by right-clicking one, selecting open with>choose default program and browse to the version of python you want to associate.

We are currently working on a knowledge base document to describe this issue and the process for modifying file associations/targeting the right version of python.

View solution in original post

0 Kudos
12 Replies
ChristopherBlinn1
Occasional Contributor III
This is not so much an answer or suggestion but a relative experience reply...

In the past, and currently, when using DB connections in a python script I have created a connection in a folder outside of the AppData directory, i.e. C:\Scripts\DBConn\my.connection.sde

Then I reference the DB connection file in that directory for my models and scripts.

This has always been beneficial, especially if I want to run the scripts in a batch environment.

Finding "Database Connections" has been an issue many times prior to using the above example.  It has definitely saved me a headache or two.

All the best,
Chris B.
0 Kudos
ChrisFox3
Occasional Contributor III
I just installed 10.1 on my PC.   Now when I run my Python script it no longer recognizes any connection coded like "Database Connection\Connection to ...".    These connections work in ArcMap and ArcCatalog.   When I create a Model using these connections, the model works.   When I export the Model to a Python script the model it fails.    If I replace the "Database Connections\..." path prefix with something like "C:\Users\SomeUser\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog\..." it works.   In short Python is not resolving "Database Connections" to the actual location of the connections (ie. "C:\Users\SomeUser\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog").   I have SP1 installed on the ArcGIS 10.1 for Desktop.    My C: drive has both a "Python26" and a "Python27" directory.   Maybe its getting confused where to run Python?    Also it looks like ArcCatalog/ArcMap run as 32 bit where as Python runs as 64-bit.   Is there something I can do to configure the 64-bit side to find "Database Connections".   

Please help!   Thanks!


How are you running the python script? To be sure you are running against the same version of python ArcGIS Desktop will run you can explicitly call the version of python from a command prompt and then pass in the path to the script. This blog talks about it, but specifically in regards to targeting the 64 bit install of python. You can do the same for the 32 bit install.

http://blogs.esri.com/esri/arcgis/2012/11/12/python-scripting-with-64-bit-processing/
0 Kudos
GregoryDillon
New Contributor III
How are you running the python script? To be sure you are running against the same version of python ArcGIS Desktop will run you can explicitly call the version of python from a command prompt and then pass in the path to the script. This blog talks about it, but specifically in regards to targeting the 64 bit install of python. You can do the same for the 32 bit install.

http://blogs.esri.com/esri/arcgis/2012/11/12/python-scripting-with-64-bit-processing/



Thanks for the hint.   I was able to run my Python script file with references to "Database Connections" if I use 32-bit Python (ie.  C:\Python27\ArcGIS10.1\python.exe").


Okay now that the "Bug" has been identified, can somebody from ESRI tell me how to fix it.    Thanks.
0 Kudos
ChrisFox3
Occasional Contributor III
This is not a bug in the software. When you run python against the 64 bit install of python and arcpy, you are running against the Server install and Server doesn't know about the relative location of the "Database Connections" which lives under the Desktop10.X folder in your user profile. If you publish a geoprocessing script tool to Server that has a hardcoded path to Database Connections we actually copy the connection file as part of the package and modify the script to point to the packaged connection file.

So your options are to reference the full path to the connection file or always ensure you are running the script against the 32 bit or Destkop install of python.
0 Kudos
GregoryDillon
New Contributor III
This is not a bug in the software. When you run python against the 64 bit install of python and arcpy, you are running against the Server install and Server doesn't know about the relative location of the "Database Connections" which lives under the Desktop10.X folder in your user profile. If you publish a geoprocessing script tool to Server that has a hardcoded path to Database Connections we actually copy the connection file as part of the package and modify the script to point to the packaged connection file.

So your options are to reference the full path to the connection file or always ensure you are running the script against the 32 bit or Destkop install of python.


I disagree it not a BUG.   If I run the model, export it to a script and immediately run it in the default (64bit) Python - it fails!   Maybe the export should be smarter and thats where the bug lies?    Is what you say documented?
0 Kudos
ChrisFox3
Occasional Contributor III
I can see the arguement for logging an enhancement when exporting a model to a python script using the "Database Connections" keyword in the path that we automatically write out the full path to the connection file instead of using just Database Connections.

However targeting the wrong version of python when executing your scripts is the much bigger issue here. You would see the same problem if your script tried to process a personal geodatabase feature class, because PGDB is not supported with ArcGIS Server, or if you tried to use some of the metadata tools because they are not supported in Server. We can't do anything about this when exporting the python script because a python script itself cannot explicitly target a version of python to run against at python 2.7. Here is a python bug that describes this limitation and the ultimate solution at Python 3.3.

http://bugs.python.org/issue4485

This all comes back to file associations. If you installed ArcGIS Desktop first and then installed ArcGIS Server, the file associations for a .py file would be set to the 64 bit version of python 2.7 or the last version of python installed, so if I double-click to the script it would execute against Python 2.7 64 bit. Let's say I then installed stand-alone Python 3.0, then the file associations for .py would be set to Python 3.0 and if I double-clicked to run my script it would fail when importing arcpy. You can modify the file associations of .py files by right-clicking one, selecting open with>choose default program and browse to the version of python you want to associate.

We are currently working on a knowledge base document to describe this issue and the process for modifying file associations/targeting the right version of python.
0 Kudos
GregoryDillon
New Contributor III
Seems having the export write the whole path is the way ESRI should go since that works in 32-bit and 64-bit.  

I think it would be good to post the documentation link for this issue when it get documented.


I've decided to just copy the connections to a seperate folder that I will hard code in my script.   I feel this is a better solution than pointing to "C:\Users\SomeUser\AppData..." since this path varies from logins across multiple PCs and Servers where I test and deploy my scripts.    This means when I add or change a connection I will need to redeploy it to my special script connection folder.   I find this distrubing since its another step I could miss in the deploy.
0 Kudos
eddiequinlan
Occasional Contributor
Hi all,

I'm having a difficult time with the odc connections in 10.1 and python.  All my python scripts worked like a charm in 10.0, now that I'm migrating (migrane) to 10.1 I'm having the same "Database Connections" path issue.  I noted that

Originally Posted by wudgcd 
I just installed 10.1 on my PC. Now when I run my Python script it no longer recognizes any connection coded like "Database Connection\Connection to ...". These connections work in ArcMap and ArcCatalog. When I create a Model using these connections, the model works. When I export the Model to a Python script the model it fails. If I replace the "Database Connections\..." path prefix with something like "C:\Users\SomeUser\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog\..." it works. In short Python is not resolving "Database Connections" to the actual location of the connections (ie. "C:\Users\SomeUser\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog"). I have SP1 installed on the ArcGIS 10.1 for Desktop. My C: drive has both a "Python26" and a "Python27" directory. Maybe its getting confused


replaced the connection with the path.  I've tried that and it still gives the error message

".......CamaData_SQLserver.odc\dbo.PA_OLVIEW1 does not exist or is not supported"

What's the solution?  Most of my data is extracted from these odc connections.

thanx,
Eddie
0 Kudos
T__WayneWhitley
Frequent Contributor
OLE DB is not supported in 64-bit.  You have to 'qualify' with the 32-bit exe path to 'force' your script to run against the 32-bit version.
And if you can, use full pathname strings to DB connections.

Enjoy,
Wayne
0 Kudos