jdbc Oracle Database error: Can't load IA 32-bit .dll on an AMD 64-bit platform

I have added a path to system variables in order to point a 32-bit version of Oracle, because I need it to start a software that uses it.

Now, if I try to connect to Oracle DB, KNIME gives me the following error

If I remove the path to 32-bit Oracle the connection works perfectly, but I cannot use the other software.

I need either software, and I really need to connect to Oracle DB (Using DataBase Table Connector) in order to pick up the data.

Could someone help me to find a solution?

I use analytic Platform 3.6.2.
I connect to Oracle DB via OCI, and THIN connection does not work in any case.

Thanks, Andrea

Look here:
It may work for you.

izaychik63 thanks for your answer, but nothing changes.

I have temporally solved the problem copying the ocijdbc11 files (.dll and .sym) from the 64-bit Oracle Instant Client 11.2 and pasting them to the 32-bit folder, but I know that some error occurs soon.

I imagine that there was a stronger solution, maybe modifing some preferencies…

You cannot load 32bit libraries into 64bit processes and vice-versa. Therefore the only option if you really need 32bit libraries is to use a 32bit KNIME Analytics Platform installation. Which has certain drawback, of course.

Hi thor, thanks for the answer.

The problem is different.
I have a 64-bit system with a 64-bit Oracle Client and a 64-bit KNIME Analytic Platform.

There is company software that needs a 32-bit Oracle Client, so I have put this client into the Oracle path, and I have added this path in system variables, before the path of 64-bit Oracle Client.
This procedure ensure that the company software works correctly.

If I want to connet to Oracle DB from KNIME Analytic Platform, now, KNIME follows the first path written in system variables.
Instead, if I put the 32-bit path AFTER the 64-bit one, the Oracle connection works, but the Company software not.

My question was about this: Can I define a path in KNIME Analytic Platform, in order to bypass the problem?

My (stupid) solution for the moment is to copy the 64-bit .dll needed files into the 32-bit one. Luckely the software does not use these files…