Omnis Technical Note TNSQ0020 April 2008
Connecting to an Oracle 64-bit (x64) Server
For Omnis Studio 4.3 and later
By Gary Ashford
We have recently been made aware of problems connecting to the Windows 64 bit version of Oracle Enterprise Server from Omnis Studio running on the same machine. The problem is characterised by one of the following error messages when attempting to logon via the Oracle DAM (DAMORA8):
| ORA-06413: Connection not open
orORA-12154: TNS:could not resolve the connect identifier specified
In tests, we have found that it is possible to connect:
- From a remote 32-bit machine to a database running on the 64-bit server.
- Locally from the 32-bit version of Omnis Studio running on the 64-bit machine.
- Remotely to a 32-bit database server from Studio running on the 64-bit machine.
In all cases, the 32-bit Oracle Client library (oci.dll) must be used-
since the Oracle DAM is a 32-bit component. If Omnis detects the 64-bit
version of oci.dll (installed in the server folder), the DAM will fail
to load and there will be an error in the trace log stating that
"%1 is not a valid Win32 application".
For this reason you should ensure that the path to the 32-bit DLL appears before the path to the 64-bit DLL when inspecting the Path environment variable on the Windows 64-bit machine. For example:
The error message that appears at logon is caused by a known networking bug in the Oracle clientware, whereby the networking layer is unable to parse program locations that contain parentheses in the path to the executable which is attempting to connect to Oracle. This is the case for the Windows Server 2003 R2 x64 operating system, since all 32-bit applications are automatically installed to a folder named: "C:\Program Files (x86)" with "C:\Program Files" being reserved for 64-bit applications.
To work around this issue, it is therefore necessary to move/install
Omnis Studio to a location that does not contain parentheses (or quotation
marks)- ideally; "C:\Program Files\Raining Data\".
Please refer to the forum thread at the foot of this technote for further details about this issue.
In tests, we used the Oracle Easy Connect naming method when connecting to the local server instance. This avoids the need for a tnsnames.ora file as the connection parameters are specified in the host parameter of the Oracle DAM $logon() method. For example:
To connect from the 64-bit machine to an Oracle 32/64-bit server running
on a remote machine, these can be specified using the tnsnames.ora file
associated with the 32-bit client software (Oracle Instant Client in this
case) or using Easy Connect naming if the remote server is using this
Likewise, from a remote 32-bit client- you can connect to the 64-bit server instance using any of its supported naming methods.
The information in this technote is based on tests run using an Intel
Pentium D class (x64) PC with Microsoft Windows Server 2003 R2 (x64) Edition
and Oracle Enterprise 10g (10.2.0.1) 64-bit edition.
Local and remote tests were performed using Omnis Studio 4.3.1 and Oracle Client 10g Express Edition (Instant Client)
Although not specifically implied by this technote, it is likely that network connection errors experienced using other Omnis DAMs and 64-bit installations may also be attributable to this problem, in which case the advice given here may also be applicable.
Connecting to Oracle on 64-bit (x64) machine (SQL Server Integration Services): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=159581&SiteID=1