by Dan Iverson
Bookmark

Managing 32-bit and 64-bit Oracle Client

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:

  1. Install Oracle 32-bit client to c:\oracle2\product\12.1.0\client_1
  2. Install Oracle 64-bit client to c:\oracle\product\12.1.0\client_1

  3. 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

  4. 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

  5. Set the ORACLE_HOME environment variable to c:\windows\system32\oracle.

  6. (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.

8 thoughts on “Managing 32-bit and 64-bit Oracle Client”

  1. 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?

    Reply

    1. It is quite confusing, but the last paragraph is correct. On 64-bit Windows systems, the sysWOW64 folder holds 32-bit binaries. The system32 folder holds 64-bit binaries. No idea why the people at Microsoft decided on the setup, but that’s they way it is.

      Reply
  3. Pingback: #31 – Change Assistant – psadmin.io

  4. Nice 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.

    Reply
  5. Pingback: #277 – Monitoring Tool

    1. 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.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks: 

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax