Possible to force GTX to use 64-bit Oracle client
We have ArcGIS Server v10.0 (32 bit) and GTX Essentials (64 bit) installed on the same server. We're using a 64-bit Oracle client since we have Oracle datalinks in GTX Essentials. We also want to start using query layers in ArcGIS Server, but we have to use a 32-bit Oracle client to do so. We can install both 32- and 64-bit Oracle clients on the same server with different ORACLE_HOMEs, but is it possible to force GTX to use the 64-bit ORACLE_HOME while forcing ArcGIS Server to use the 32-bit ORACLE_HOME (or simply using a default of 32-bit for everything except GTX and force GTX to use 64-bit)?
-
Follow-up: we're running on Windows Server 2008 R2 SP1. Also, our ArcGIS and GTX app pools run under different identities.
0 -
Geocortex Essentials is a 32 bit compiled application, and from my experience uses the 32 bit Oracle client. Be sure the essentials and essentials admin local app pool users have access to run the oracle client, or it will not work. Reboot the server to be sure any oracle client folder permissions are affected the (typically) already running Oracle client.
0 -
Actually, Essentials can run as a 64-bit application now, and this is the standard configuration for a fresh install on a 64-bit server. Basically, if it is running in 64-bit application pools in IIS, it will be a 64-bit application and need the 64-bit Oracle libraries.
However, if you go into IIS and change the app pool settings to 'allow 32-bit applications' the application pools will become 32-bit and should then be able to load the 32-bit Oracle libraries instead.
As to your actual question -- it will probably be quite tricky to achieve this, but there still should be some way of doing it if you really need to. The main problem comes from the fact that Oracle sets the path to the drivers in your global %PATH% variable, which will either point at a 64 or 32-bit installation, and can't normally change dynamically based on the bitness of the calling process.
However, the following seems to be a relatively simple 'hack' that could fake this. This isn't tested by us -- so use at your own risk:
Given the nature of the above though, it would be strongly recommended to move processes that need to use different Oracle drivers to a different server if possible. Configurations like this just don't seem to be well supported or documented, and could cause more headaches than they solve in the long run.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
3 Kommentare