DLL load failed when importing pyodbc namespace?

[jamescrowley]

Hi guys,

I'm new to pyodbc so please forgive me if this is a newbie question,
but tried googling and couldn't really find anything! I've installed
pywin and pyodbc on Windows (all 64 bit versions), and I'm getting the
following when importing the pyodbc namespace:

Error was: DLL load failed: A dynamic link library (DLL)
initialization routine failed.

(I'm not even calling pyodbc.connect or anything). Does anyone have
any ideas what the cause might be or how I can track this down
further?

Thanks!

James

[mkleehammer]

I'm still resolving this, but in the meantime, I think the workaround
is to install the Visual Studio 2008 runtime:

http://www.microsoft.com/downloads/en/details.aspx?familyid=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

I'm not sure why this is occuring, because Python itself ships with
the necessary files, but the Python build scripts seem to be linking
with the wrong version or something.

Let us know if this helps.

[James Crowley]

hey - that runtime is actually already installed (both the x86 and x64 bit version). I've tried using procmon to see what files it fails on. I see it loading:

• pyodbc.pyd in site-packages
• odbc32.dll from c:\windows\system32
• msvcr90.dll (that's the runtime you mentioned, I believe?)
• odbcint.dll

It then seems to look for a registry key in HKLM\Software\ODBC\Odbc.ini\ODBC which it doesn't find...? Is there supposed to be anything there? As far as I can tell all the files it loads after that are standard Python files to then display the error message.

Thanks

James

--
You received this message because you are subscribed to the Google Groups "pyodbc" group.
To post to this group, send email to pyo...@googlegroups.com.
To unsubscribe from this group, send email to pyodbc+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyodbc?hl=en.

--

---
James Crowley
CEO, developerFusion - the global developer community - http://www.developerfusion.com/
CTO, TechEye - all the technology news unfit for print - http://www.techeye.net/

linkedin: http://linkedin.com/in/jamescrowley
twitter: http://twitter.com/jamescrowley

[James Crowley]

any thoughts on this one? :)

basically trying to get up and running on either django-pyodbc or django-mssql (which I see you're active on too!) but hitting issues with both at the moment!

happy to assist / provide as much information as you need to get this resolved.

Many thanks

James

[mkleehammer]

Sorry, I confused this thread with another where installing the
runtimes fixed the issue.

I believe the issue is that Python is compiled with the original
Visual C++ 2008 version, but I compiled with the later 2008 SP1
(service pack 1). Python requires and supplies one version of
MSVCR90. The pyodbc DLL requires a later version. (If you don't say
which version you need, MSVC assumes its the current version installed
on the box. Insane.)

In the meantime, you can install the later version runtimes. (The
previous link was for the original runtimes, which was incorrect.)

Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2

Microsoft Visual C++ 2008 SP1 Redistributable Package (x64)

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=BA9257CA-337F-4B40-8C14-157CFDFFEE4E

[James Crowley]

both of those runtimes are already installed too (just tried re-downloading and they both give me repair/uninstall options).

From the files being accessed via procmon (see my earlier message) it looks like the runtimes themselves aren't the issue (as it goes on to load other files after the msvcr90.dll). Could it be those odbc registry keys it's looking for?

--

You received this message because you are subscribed to the Google Groups "pyodbc" group.
To post to this group, send email to pyo...@googlegroups.com.
To unsubscribe from this group, send email to pyodbc+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyodbc?hl=en.

[mkleehammer]

Still researching, so let me gather some more information:

1) What version of Python are you using?
2) Python 32-bit or 64-bit?
3) What version of pyodbc?
4) And finally, did you build it or was it an installer from
code.google.com or from this newsgroup?

Thanks...

[James Crowley]

Python 2.7 64bit, and pyodbc was installed using this link

http://code.google.com/p/pyodbc/downloads/detail?name=pyodbc-2.1.8.win-amd64-py2.7.exe

Thanks so much for your help narrowing this down :)

Sent from my mobile

[mkleehammer]

OK, I've built a new Windows 7 64-bit machine and I'm getting a
similar error with the Python 3.1 version of pyodbc:

Traceback (most recent call last):
File "sqlservertests.py", line 1218, in <module>
import pyodbc
ImportError: DLL load failed: %1 is not a valid Win32 application.

Hopefully this is the same thing. I'll update you when I find out
more.

[mkleehammer]

Bad news - that was just a path screw up where a 32-bit interpreter
failed to load a 64-bit pyd.

[James Crowley]

Doh. Is there anything more I can do at my end to help pin this down?

Perhaps you could also run procmon and share the sequence of files and reg keys that get loaded so I can compare?
Thanks so much for this
Sent from my mobile

On 18 Sep 2010, at 05:57, mkleehammer <mklee...@gmail.com> wrote:

> Bad news - that was just a path screw up where a 32-bit interpreter
> failed to load a 64-bit pyd.
>

[Terence Lien]

Hi all,

I has the same issue on my platform
OS -> win7 x64
Python -> 2.6 x86
pyodbc ->pyodbc-2.1.8.win32-py2.6.exe
Could you provide any solution for this?
Thanks very much

On 9月18日, 上午4時19分, James Crowley <james.crow...@gmail.com> wrote:
> Doh. Is there anything more I can do at my end to help pin this down?
>
> Perhaps you could also run procmon and share the sequence of files  and reg keys that get loaded so I can compare?
> Thanks so much for this
> Sent from my mobile
>

[sta]

I'm having the same issue. When I run my script alone (the one
importing pyodbc), no problem. When I try within my django app, I come
across this message "Error was: DLL load failed: The specified module
could not be found".

I'm using
Windows Vista x86
Python 2.7 x86
pyodbc 2.1.8.win32-py2.6 (but also tried with 2.1.7)
and I installed both python and pyodbc from the installer.

Any update on this?

Regards,
Sebastien Tandel

[Michael Kleehammer]

If it works standalone, it should work in django as long as the PYTHONPATH is similar.  In both, try printing the contents of "sys.path" in both.

[ישי בארי‎]

We're seeing the same issues; after some research we see that:

* Things work (TM) when running standalone (python.exe), but fail when
loading as DLL (in our case, django-mssql or django-pyodbc)
* This DLL load problem isn't specific to pyodbc, and happens with
many other python extensions
* Works like a charm with python 2.5, but fails with 2.6 and 2.7

All this led us to believe this is closely related to http://bugs.python.org/issue4566
and its many relatives.

Finally, with pyodbc we saw a strange thing:

* Using the latest installer downloaded from code.google.com (http://
code.google.com/p/pyodbc/downloads/detail?name=pyodbc-2.1.8.win32-
py2.6.exe) , things work even when running under IIS as a DLL
* However, when we compiled trunk ourselves in VS 2008 (we needed the
latest bugfixes), the resulting DLL fails as described above
* Compiling with /MT (static link) seemed to solve things for now -
but I'm not sure this is the proper way to go about this

Seems like there are some subtle implications to the exact version(s)
of the runtime used during compilation and present or not during
runtime - and the various paths available to the DLL when loading as
service or under IIS instead of in a "normal" python.exe launch.

Michael, we will be happy to help solve this in any way we can. Can
you kindly tell us more about the exact env you use to compile the
binaries available on code.google.com?
In addition, can you possibly compile such a binary installer from
pyodbc trunk, on your env, that we can test to see if it magically
works as the previous one did?



On Dec 8 2010, 10:06 pm, Michael Kleehammer <mkleeham...@gmail.com>
wrote:

[Peter]

I've wrestled with python and SxS native assemblies before. Perhaps
this information is of use to this group:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/3ec6af1279a162ca/82caa7deae54ee0a?hl=en&ie=UTF-8&q=peter+santoro+comp.lang.python#82caa7deae54ee0a

search http://groups.google.com/group/modwsgi using my name "Peter
Santoro" and sort by date

Take care,

Peter Santoro

[Michael Kleehammer]

I believe the reason you are seeing a difference between the supplied build and your own is that the versions of Visual C++ are slightly different due to different service packs.  Each service pack creates a new version of the C runtime DLL.  My guess is you have one installed on your target machine the pyodbc build, but you do not have the same DLLs from your own version of Visual C++.  (The build machine and test machine are different, right?)

For the record, the underlying problem is that the Visual C++ runtime DLL startup code checks to see if it matches the build in your executable.  If not, it refuses to load.  This is amazingly stupid and Microsoft persisted with this for years.  The good news is that with 2010, supposedly this check has been removed.  When we all upgrade to versions of Python built with Visual Studio 2010, the problem should go away.

In the meantime, there are some workarounds:

• Probably the best workaround is to have a build machine that has the same version of Visual C++ installed that was used to build the official Python distribution.  This should help, though all extension vendors may not do the same.
• The most obvious is to install the Visual C++ runtime redistributable that exactly matches your version of Visual Studio.  It is an installer package that is shipped with VC++, so it is easy to ensure you have the right one.  You can also install every runtime version since they do not conflict.  (See Peter's post.)
• You can modify the manifest in all of the executables and DLLs to match the installed DLL versions or the official Python version.  I do this for an important project using pyodbc and a host of other C extensions.  I extracted the manifest from python.exe, modified it slightly and use it to build with.  I also post process any extensions I didn't build and replace the version numbers in the DLL's embedded XML file to match.  This works very well.

For the record, my version of Visual Studio 2008 is:

Microsoft Visual Studio 2008

Version 9.0.30729.1 SP

Microsoft .NET Framework

Version 3.5 SP1

I don't do anything else special in the pyodbc build process.