Beginning with PeopleTools 8.54, the PeopleTools client tools became 64-bit applications. This means the client tools require the 64-bit Oracle client. If are still running on PeopleTools 8.53 (or earlier), you’ll need both 32-bit and 64-bit Oracle clients installed. Managing both versions can be cumbersone, and often times frustrating.
Tim Slater offered a great solution for managing Oracle clients in the psadmin.io Community. Here is Tim’s method for managing Oracle clients:
- Install Oracle 32-bit client to
c:\oracle2\product\12.1.0\client_1 - Install Oracle 64-bit client to
c:\oracle\product\12.1.0\client_1 -
Create a symbolic link
c:\windows\system32\oracleto point to the 64-bit installation folder.mklink /j c:\windows\system32\oracle c:\oracle\product\12.1.0\client_1 -
Create a symbolic link
c:\windows\sysWOW64\oracleto point to the 32-bit installation folder.mklink /j c:\windows\sysWOW64\oracle c:\oracle2\product\12.1.0\client_1 -
Set the
ORACLE_HOMEenvironment variable toc:\windows\system32\oracle. -
(Optional) Set the
TNS_ADMINenvironment variable to%ORACLE_HOME%\network\admin
This works because of File System Redirection in 64-bit versions of Windows. If you are running a 64-bit application, Windows will route any system calls to c:\windows\system32. But, if you are running a 32-bit application, any system calls are routed to c:\system\sysWOW64 instead. Rather than manually configuring your applications and updating the PATH environment variable, you can let Windows do the work for you.
I am not a PSAdmin, so your last paragraph is confusing to me…it says ‘If you are running a 64-bit application, Windows will route any system calls to c:\windows\system32. But, if you are running a 32-bit application, any system calls are routed to c:\system\sysWOW64 instead. ‘
That seems backwards to me…if you’re running a 64-bit application, wouldn’t it be routed to the c:\system\sysWOW64 path?
It is quite confusing, but the last paragraph is correct. On 64-bit Windows systems, the
sysWOW64folder holds 32-bit binaries. Thesystem32folder holds 64-bit binaries. No idea why the people at Microsoft decided on the setup, but that’s they way it is.WOW64 stands for
Windows 32bitonWindows64bitNice hack.
Couldn’t fix this issue even with Application Compatibility Toolkit.
This one works.
I think it’s better to have single tnsnames.ora.
So, either TNS_ADMIN should point to absolute path with single correct tnsnames.ora. Or tnsnames.ora in one client should be hard link pointing to the one in the second client.
is /D or /J needed? Per this MS documentation, /J is a “Directory Junction” whereas /D is a “Symbolic Link”
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink
Hi, i’m no expert on the issue, but as far as i know, in the end they’re working very similarly and are often interexchangeable. However, the biggest limitation for a directory junction is that you can only use it on mapped drives and folders, while a Symbollic link can also use UNC paths.
Like a Directoy junction can only call on a mapped network drive like “N:\network\place\”
whereas the Symbollic link can either use “N:\network\place\” or “\server\network\place”.
But since it’s meant to do locally, it’s the same what you pick.
This solution sounds convincing …
I have a concern related to the Path Variable … As you know any time you install Oracle “it adds” the oracle client install location into the beginning of the Path variable… In the proposed solution the path variable will look like this:
c:\oracle\product\12.1.0\client_1;c:\oracle2\product\12.1.0\client_1;…..
Anytime an app looks for oracle it should stop after finding the first instance in the path … then it will never reach the 32-bit client … Or I am wrong …
Is there a modification in the path variable that need to be made as well … or it will resolve by itself?
I was wondering if you may advise on this.