Re: [cx-oracle-users] Using cx_Oracle 6.0rc1 on Windows

[Anthony T. <ant...@gm...>]

On Tue, Jul 11, 2017 at 7:49 AM, Walter Dörwald <wa...@li...>
wrote:

> On 6 Jul 2017, at 19:11, Anthony Tuininga wrote:
>
> On Thu, Jul 6, 2017 at 9:48 AM, Walter Dörwald <wa...@li...>
>> wrote:
>>
>> On 6 Jul 2017, at 0:45, Anthony Tuininga wrote:
>>>
>>> On Wed, Jul 5, 2017 at 4:12 PM, Anthony Tuininga <
>>>
>>>> ant...@gm...
>>>> [...]
>>>> Just to be clear since the process is a bit different now: in your
>>>> cx_Oracle repository you need to issue the following commands:
>>>>
>>>> git pull
>>>> git submodule update
>>>>
>>>>
>>> "git submodule update" doesn't seem to do anything. Do we need a special
>>> git configuration for that?
>>>
>>>
>> No. But if you didn't initialise the submodule when you first cloned
>> cx_Oracle that would happen. The correct steps for initial cloning is as
>> follows:
>>
>> git clone https://github.com/oracle/python-cx_Oracle.git cx_Oracle
>> cd cx_Oracle
>> git submodule init
>>
>> Making odpi empty and doing "git clone https://github.com/oracle/odpi"
>>> helps.
>>>
>>
>> The submodule is used so that you get the right version of ODPI-C. Right
>> now there aren't any incompatible changes in ODPI-C but that will change
>> in
>> the future. So you don't want to do this long-term!
>>
>
> OK, that works.


Excellent.


>
>
> That will update ODPI-C (where the correction was made) as well as
>>>
>>>> cx_Oracle itself.
>>>>
>>>>
>>> With this (and a python -v), we do indeed get the following:
>>>
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "<frozen importlib._bootstrap>", line 961, in _find_and_load
>>>   File "<frozen importlib._bootstrap>", line 950, in
>>> _find_and_load_unlocked
>>>   File "<frozen importlib._bootstrap>", line 648, in _load_unlocked
>>>   File "<frozen importlib._bootstrap>", line 560, in module_from_spec
>>>   File "<frozen importlib._bootstrap_external>", line 922, in
>>> create_module
>>>   File "<frozen importlib._bootstrap>", line 205, in
>>> _call_with_frames_removed
>>> cx_Oracle.DatabaseError: DPI-1047: Oracle Client library cannot be
>>> loaded:
>>> %1 ist keine zulässige Win32-Anwendung. See
>>> https://oracle.github.io/odpi/
>>> doc/installation.html for help
>>>
>>
>> Excellent. Thanks for confirming.
>>
>>
>>> [...]
>>>
>>>> And of cause it would help if %1 was resolved to a useful filename.
>>>>>>>
>>>>>>>
>>>>>> Naturally. But that information isn't directly provided. I'll look
>>>>>> into
>>>>>> that, too.
>>>>>>
>>>>>>
>>>>> This is a limitation of Windows and there isn't much that can be done
>>>>> about it. Sorry!
>>>>>
>>>>>
>>>> May be the %1 is supposed to be the argument that was passed to
>>> LoadLibrary()?
>>>
>>>
>> I believe it is supposed to refer to the *actual* DLL that caused the
>> problem -- but as far as I know there isn't a way to get this value. The
>> value passed to LoadLibrary() is simply "oci.dll" so that doesn't help
>> much.
>>
>
> True, and the error could be a completely unrelated one. It seems that the
> Windows error API is not well thought out.


Unfortunately, yes. :-(


>
>
> The installation documentation linked to in the error message gives
>> you that much!
>>
>>>
>>> According to the documentation of FormatMessageW() at
>>>
>>>    https://msdn.microsoft.com/en-us/library/windows/desktop/
>>> ms679351(v=vs.85).aspx
>>>
>>> it should by possible to pass in arguments to FormatMessageW() in the
>>> last
>>> parameter.
>>>
>>>
>> Yes, it does.
>>
>>
>>> At least this would mean that the user gets to see the path to the
>>> cx_Oracle DLL.
>>>
>>>
>> But how does one get that information? As far as I know there isn't a way
>> to get it. See the comments here:
>> https://stackoverflow.com/questions/6190105/formatmessage-
>> with-placeholders.
>>
>>
>>> Of course it would be better, if we could see which DLL ultimately is the
>>> problem.
>>>
>>
>> Definitely! Too bad Microsoft doesn't provide that information. :-(
>>
>>
>>
>>> But now for the real error...
>>>
>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>
>>>>>>>> You can use this tool: http://www.dependencywalker.com/ which will
>>>>>>>> tell you
>>>>>>>> what dependencies the cx_Oracle.pyd file and all of their
>>>>>>>> dependencies,
>>>>>>>> too. Hopefully it helps.
>>>>>>>>
>>>>>>>>
>>>>>>>> OK, we tried that. The output is here:
>>>>>>>
>>>>>>>    http://styx.livinglogic.de/~walter/cx_Oracle/cx_Oracle.cp36
>>>>>>> -win_amd64.txt
>>>>>>>
>>>>>>> dependencywalker seem that have many problems with this DLL, but what
>>>>>>> sticks out is VCRUNTIME140.dll. This seems to be part of the "Visual
>>>>>>> C++
>>>>>>> Redistributable for Visual Studio 2015" which we downloaded from
>>>>>>> here:
>>>>>>>
>>>>>>>    https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>>>>>>
>>>>>>> (we've downloaded vc_redist.x64.exe). When we install it, it
>>>>>>> complains
>>>>>>> that another version is already installed. After we've uninstalled
>>>>>>> the
>>>>>>> 2017
>>>>>>> Redistributables installation works, but the output of "import
>>>>>>> cx_Oracle"
>>>>>>> remains the same.
>>>>>>>
>>>>>>>
>>>>>>> So the problem isn't resolved by the change of VS redistributable.
>>>>>> Can
>>>>>> you take a look in the event log? Can you also provide a list of all
>>>>>> of
>>>>>> the
>>>>>> VS redistributables you have installed? I am going to try to replicate
>>>>>> this
>>>>>> myself.
>>>>>>
>>>>>>
>>>>> OK, the list is here:
>>>
>>>    http://styx.livinglogic.de/~walter/cx_Oracle/VCRedistributables.png
>>>
>>>
>>> Thanks. I have downloaded VS 2017 and will attempt to build with it. I
>> know
>> that Python itself was built with VS 2015 so that redistributable will be
>> needed but the 2017 one will also probably be needed. I'll let you know if
>> I am able to replicate your issue.
>>
>
> Any luck so far?
>

I was able to get VS 2017 and was able to compile cx_Oracle with it. I
didn't run into any problems at all. I was using an instant client,
however, so not sure if that has any bearing.


>
> What we could try is to use the Oracle Instant Client instead of Oracle 11
> XE and see if this changes anything.


Please let us know if this does change things in any way.

A new release will be made sometime next week, if at all possible, so you
can get binary releases directly for it with this and other fixes included
in it. There will also be some updated documentation on installation which
will encapsulate some of this information -- so if you do find out that
Oracle 11 XE is the culprit it would be very good to know! Thanks.


>
>
> Servus,
>    Walter
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>