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\oracle
to 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\oracle
to point to the 32-bit installation folder.mklink /j c:\windows\sysWOW64\oracle c:\oracle2\product\12.1.0\client_1
-
Set the
ORACLE_HOME
environment variable toc:\windows\system32\oracle
. -
(Optional) Set the
TNS_ADMIN
environment 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
sysWOW64
folder holds 32-bit binaries. Thesystem32
folder 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
W
indows 32bito
nW
indows64
bitNice 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.