64-bit ODBC

64-bit ODBC primer — when to use a 64-bit ODBC driver; ODBC issues on 64-bit Linux, UNIX and Windows platforms; background information on 64-bit architecture, operating systems and programming models.

Introduction
ODBC on 64-bit Platforms
Frequently Asked Questions

Introduction

32-bit computer hardware is based on a processor capable of manipulating 32 bits (binary digits) of information at a time and using 32 bits to represent memory addresses. 64-bit hardware uses 64 bits to do the same thing. Usually, 32-bit operating systems run on 32-bit hardware, although it is possible to run 32-bit operating systems on some 64-bit computers. 64-bit operating systems run on 64-bit hardware.

Operating systems consist of a kernel (which allocates system resources, launches applications and manages memory, files and peripheral devices) and operating system libraries. 32-bit operating systems have a 32-bit kernel. 64-bit operating systems have a 64-bit kernel. Some operating systems, for example Solaris 7.0+ and AIX 5, can boot either a 32-bit or a 64-bit kernel. A 64-bit kernel is required to run 64-bit applications. (On AIX 5, IBM state that 32-bit and 64-bit applications can run with either a 32-bit or 64-bit kernel. However, for applications that use kernel extensions, this is conditional on the support for the extension in both kernels.) An operating system with a 64-bit kernel can also run 32-bit applications.

Operating system libraries are required to build and run applications. To build 32-bit applications, they must be linked to 32-bit system libraries. To build 64-bit applications, they must be linked to 64-bit system libraries.

32-bit applications are compiled such that memory addresses are 32-bit (4 bytes) in size. These applications can directly access up to 4 GB of virtual memory (the memory potentially available for use on a computer, which may be partially simulated by secondary storage such as a hard disk). This virtual memory limit is present regardless of the amount of physical memory installed on the machine. By contrast, 64-bit applications are compiled such that memory addresses are 64-bits (8 bytes) in size and can use more than 4 GB of virtual memory.

64-bit applications require a machine with a 64-bit processor and a 64-bit operating system. 32-bit applications can be run on both 32-bit and 64-bit machines/operating systems. However, only 64-bit applications can take advantage of the 64-bit capabilities of the processor and operating system. Depending on the application, these may include the 64-bit memory addressing and arithmetic capabilities of the processor, as well as increased system resources provided by the operating system.

Advantages of 64-bit Computing

A 32-bit processor can handle a 32-bit integer, and a 64-bit processor can handle a 64-bit integer. A 64-bit processor can therefore handle a larger range of integer values. Since memory addresses are integers that specify a location in memory, a processor that can handle more integer values can also handle more memory addresses. (Each byte of memory in a computer must have a unique address so that applications can keep track of and identify the memory.)

On 32-bit machines, memory addresses are 32 bits in length and stored as base-2 numbers. (The base-2, or "binary," number system expresses integer values as combinations of two digits: 0 and 1.) There are approximately 4 billion possible different 32-bit binary numbers (2³²), which accounts for the 4 GB memory address space limit on machines with a 32-bit processor.

By contrast, a 64-bit processor can theoretically address up to 16 exabytes (EB) (2⁶⁴ bytes) of memory, giving access therefore to practically unlimited memory.

64-bit memory addressing enables applications to store large data sets entirely in memory. This eliminates the performance penalty associated with swapping portions of the data in and out to disk. For example, the increased memory space available on a 64-bit platform enables large databases to be preloaded into memory, improving data access times for database client applications. Memory is accessed hundreds of times faster than disk drives, so replacing I/O access to data with access via memory is extremely beneficial for database performance. Because more database operations can run at memory speed rather than disk speed, 64-bit machines enable databases to scale to support more users.

On 32-bit systems, memory management extensions exist that enable applications to use more than 4 GB of memory. These extensions are Physical Address Extension (PAE) and the Microsoft Windows-only feature Address Windowing Extension (AWE). Databases such as Oracle and SQL Server can take advantage of PAE and AWE to gain access to additional memory beyond their 4 GB limit. One constraint with PAE and AWE, however, is that memory above 4 GB can only be used to store data, it cannot be used to store or execute code. So, for example, the memory is not available to other memory consuming database operations such as caching query plans, sorting, indexing, joins, or for storing user connection information. By contrast, 64-bit machines make memory available to all database processes and operations.

Other memory intensive applications that benefit from running on a 64-bit platform include computer-aided design/computer-aided manufacturing (CAD/CAM), scientific modelling and other engineering applications. These applications usually perform optimally by holding large amounts of data in memory. Graphics programs will also see performance improvements as they, too, often deal with large amounts of data, especially when rendering 3-D imagery.

In addition, some types of data processing work more efficiently in a 64-bit environment, such as encryption. Most encryption algorithms are based on very large integers—the larger the integers, the more secure the encryption. Encryption applications can take advantage of 64-bit integers and gain a consequent performance boost on 64-bit systems.

For applications that do not need to address memory beyond the 32-bit processor limit of 4 GB, 64-bit machines still provide substantial benefits in terms of processing speed. With a 64-bit processor, each general-purpose register is 64-bits wide and can represent a much larger integer. (A register is high-speed memory within a processor that provides the fastest way for a processor to access data. A general-purpose register is available for any use rather than being reserved for a specific purpose by the processor or operating system.) Programming languages such as C and C++ can perform mathematical operations on 64-bit integers. 64-bit integer types can be contained within a single register on a 64-bit machine (as opposed to a 32-bit machine, where 64-bit numbers have to be split across two 32-bit registers). The register-width difference produces a substantial reduction in resource requirements when performing 64-bit mathematics. Mathematical operations on 64-bit numbers consume fewer registers and require fewer processor instructions on a 64-bit machine than on a 32-bit machine.

Improvements in parallel processing and bus architectures, enable 64-bit machines to support a larger number of processors (up to 64). An increased capacity for processor support means that a single machine has the potential to support more processes, applications, and users.

On Solaris machines, 32-bit applications using standard I/O are limited to 256 file descriptors, which limits the number of open files that the application can maintain. (A file descriptor is an integer used to identify an open file for the purpose of file access.) This limit is present because Solaris machines use a char type to represent the file descriptors, which can only hold a range values of 0–255. If there are no free file descriptors in the 0-255 range, an I/O error results if the application attempts to open another file. The limit is not applicable to 64-bit applications, which can use up to 2 billion descriptors.

64-bit Unix and Linux Platforms

There are several 64-bit Unix and Linux Platforms, and these based around different 64-bit processors. For example, Easysoft ODBC drivers are available on the following 64-bit Unix and Linux platform/processor combinations:

Platform	Processor
AIX	PPC (PowerPC)
HP-UX	Itanium i64
HP-UX	PA-Risc 2 (Precision Architecture-Reduced Instruction Set Computing)
Irix	MIPS (Microprocessor without Interlocked Pipeline Stages)
Linux	x86-64
Linux	Itanium i64
Solaris	SPARC (Scalable Processor Architecture)
Tru64 UNIX	Alpha

64-bit operating systems are able to run both 32-bit and 64-bit applications concurrently. To execute correctly, each application requires a number of libraries. However, the file names for the 32-bit and 64-bit versions of these libraries are identical. They must be differentiated from each other in another way. The most common approach is to use separate directories for 32-bit and 64-bit libraries, although the naming convention used for the directory structure differs from system to system.

Linux systems that follow the Filesystem Hierarchy Standard (FHS) place 64-bit libraries in /lib64 and /usr/lib64. 32-bit libraries remain in /lib and /usr/lib. Using lib for 32-bit libraries enables 32-bit programs to work on 64-bit machines without any changes. Linux distributions that follow the FHS requirements for 32-bit/64-bit library locations include Fedora, RedHat and SUSE. For example, on this FHS-conformant Fedora system, the 64-bit version of the GNU C library is located in /lib64. The 32-version is located in /lib. The file name is the same for both 64-bit and 32-bit versions. They are separated by their location.

$ file /lib64/libc-2.7.so
/lib64/libc-2.7.so: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), for GNU/Linux 2.6.9, not stripped
$ file /lib/libc-2.7.so
/lib/libc-2.7.so: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), for GNU/Linux 2.6.9, not stripped

Solaris and HP-UX (PA-Risc) systems use a similar method to separate 32-bit and 64-bit libraries. However, although these operating systems preserve the existing 32-bit library directory structure, they use a proprietary naming convention for the 64-bit library directory. Solaris uses /usr/lib/sparcv9 (or /usr/lib/64) for 64-bit libraries and /usr/lib for 32-bit libraries. HP-UX (PA-Risc) uses /usr/lib/pa20_64 for 64-bit libraries and /usr/lib for 32-bit libraries.

HP-UX (Itanium) systems use /usr/lib/hpux32 to store 32-bit libraries and /usr/lib/hpux64 to store 64-bit libraries. (PA-Risc based libraries are also present on Itanium HP-UX systems, in the standard locations, /usr/lib and /usr/lib/pa20_64.)

Itanium 2 based Linux systems can provide 32-bit support through the Intel Architecture 32-bit Execution Layer (IA-32 EL). IA-32 EL is a software package that translates IA-32 instructions into Itanium instructions. IA-32 EL replaces the less efficient, hardware-based 32-bit support of the original Itanium processor. Linux distributions that support IA-32 EL include Red Hat Enterprise Linux and SUSE Linux Enterprise Server. The directory structure for 32-bit libraries installed under IA-32 EL is /emul/ia32-linux/lib and /emul/ia32-linux/usr/lib. 64-bit libraries are installed in /lib and /usr/lib.

On AIX systems, most system libraries are hybrid mode archives—a single library archive file that contains both 32-bit and 64-bit versions of its member objects. AIX uses a "_64" file name suffix to separate the 64-bit objects from the 32-bit objects. The name of the 32-bit object remains unchanged. The following command illustrates this naming convention. It lists both 32-bit and 64-bit object modules contained in the standard C library, libc.a:

$ ar -X 32_64 -t /usr/lib/libc.a
frexp.o
itrunc.o
ldexp.o
.
.
.
frexp_64.o
itrunc_64.o
ldexp_64.o
.
.
.

64-bit Windows Platforms

64-bit Windows is available for systems based on these processor platforms:

x64: AMD-64 (Athlon-64, Opteron and Turion processors) and Intel EMT-64 (Pentium D, Xeon, Core Duo and Core 2 Duo).
Intel Itanium.

For example, there are x64 editions of Microsoft Windows Vista, Microsoft Windows Server 2003 and Microsoft Windows XP; there are Itanium editions of Windows Server 2003 and Microsoft Windows Server 2008.

64-bit Windows platforms support both 32-bit and 64-bit applications. On 64-bit Microsoft Windows platforms, 32-bit applications run in the Windows-on-Windows (WOW64) subsytem. WOW64 emulates the 32-bit Windows Operating System to allow 32-bit applications to run without modification.

A limitation of WOW64 is that 32-bit processes cannot load a 64-bit dynamic-link libraries (DLLs) and 64-bit processes cannot load a 32-bit DLLs. As the Windows system directory contains both the installed applications and their DLLs, it must be separated into a native system directory for 64-bit applications (%windir%\system32) and a WOW64 directory for the 32-bit applications (%windir%\syswow64). To enable 32-bit applications to transparently access the WOW64 system directory, the WOW64 layer provides a file system redirector. Attempts to access the %windir%\system32 directory by a WOW64 process are redirected to the %windir%\syswow64 directory.

The Itanium-based versions of Windows Server 2003 (SP1) and Windows XP use IA-32 EL to support 32-bit applications. IA-32 EL translates processor instructions between the 32-bit and 64-bit instruction sets and cooperates with the WOW64 subsystem to run 32-bit applications.

64-bit Data Models

A data model specifies the size of data types imposed by the underlying architecture. It is usually implemented by the operating systems so that multiple data models can be used on the same processor.

In the 32-bit data model (known as the ILP32 model), int, long and pointer (the ILP part of the acronym) data types are 32 bits in length. Because ILP32 lacks 64-bit pointers, the model is inappropriate for use with 64-bit processors, which are able to address large amounts of memory (beyond the 4 GB ceiling imposed by 32-bit systems). By contrast, 64-bit data models provide 64-bit pointers to take advantage of the larger address space provided by 64-bit processors.

The 32-bit (ILP32) and 64-bit (LP64, LLP64, ILP64) data models are shown in the following table. The table shows the size of the data types in bits.

Data types	ILP32	LP64	LLP64	ILP64
char	8	8	8	8
short	16	16	16	16
int32	-	-	-	32
int	32	32	32	64
long	32	64	32	64
long long (int64)	-	-	64	-
pointer	32	64	64	64

The difference between the three 64-bit models (LP64, LLP64 and ILP64) lies in the non-pointer data types. With two of the three 64-bit data models (LP64 and LLP64), it is no longer valid to assume that int, long and pointers data types are the same size. Applications whose code makes this assumption often cease to work properly when compiled on a 64-bit platform.

LP64 is the standard data model on 64-bit Linux and Unix systems. In the LP64 model, longs and pointers are 64 bits wide and ints remain fixed at 32 bits. The advantage of this data model is that it provides 64-bit addressing (64-bit pointers), 64-bit arithmetic (64-bit longs), backward compatibility (most ints in existing applications can remain as 32 bits in a 64-bit environment) and portability (does not require new data types such as int32 and int64). The difference in the size of long and pointer between ILP32 and LP64 can cause data truncation issues in code that assumes these types are the same width as ints.

LLP64 is the standard data model on 64-bit Windows systems, and is sometimes described as a 32-bit model with 64-bit addresses. In the LLP64 model, pointers are 64 bit; the other types remain unchanged from the ILP32 model. int or long variables that need to be 64 bits in length are changed to long long (also know as int64), a non-standard data type introduced by the LLP64 model.

ILP64 preserves the relationship between the three basic types that ILP32 developers are used to by making int, long and pointer types the same size. Converting or assigning pointers to int or long does not result in data truncation. The disadvantage of the ILP64 data model is that it depends on a new data type (int32) for 32-bit ints. This makes it difficult to write code that can run on both 32-bit and 64-bit platforms without resorting to conditional compilation.

ODBC on 64-bit Platforms

Background

In the original ODBC API specification and header files, the SQLINTEGER and SQLUINTEGER types, used for passing and returning data buffer lengths, were 32-bit values. In the underlying data model, ILP32, these types are 32-bit longs. Microsoft subsequently introduced two new types for data buffer arguments, SQLLEN and SQLULEN, and changed some ODBC APIs to use the new types. In version 3.52 of the ODBC specification, Microsoft changed the SQLLEN and SQLULEN types for 64-bit Windows platforms. On 64-bit Windows, the SQLLEN and SQLULEN types were changed from longs to long longs. Even though longs are 32-bit in the 64-bit Windows data model, LLP64, long longs are 64-bit.

On 64-bit Windows, pointers are 64-bit, which gives 64-bit ODBC applications the potential to take advantage of 64-bit memory addressing. For example, an application could use 64-bit addressing to provide a large buffer for LOB data. A 32-bit value may not be sufficient to return the length of data in a large buffer on 64-bit platforms. This may be the reason why Microsoft chose to increase the size of the SQLLEN and SQLULEN types from 32-bit longs to 64-bit long longs.

ODBC on 64-bit Linux and Unix Platforms

unixODBC Driver Manager

It is possible to build the unixODBC ODBC driver manager on 64-bit platforms with either 32-bit or 64-bit SQLLEN/SQLULEN types.

unixODBC 2.2.12

The default behaviour for unixODBC 2.2.12 is to build the driver manager with 32-bit SQLLEN/SQLULEN types. The BUILD_REAL_64_BIT_MODE and SIZEOF_LONG macros in unixodbc_dist_dir/include/sqltypes.h determine whether these types are 32-bit (the default) or 64-bit. To build unixODBC 2.2.12 with 64-bit SQLLEN/SQLULEN types:

Download the unixODBC distribution, unpack and cd into the directory created by unpacking the distribution file:
```
$ gunzip unixODBC-2.2.12.tar.gz
$ tar -xvf unixODBC-2.2.12.tar
$ cd unixODBC-2.2.12
```
Use the CPPFLAGS environment variable to define BUILD_REAL_64_BIT_MODE and set SIZEOF_LONG to 8:
```
$ CPPFLAGS="-DBUILD_REAL_64_BIT_MODE -DSIZEOF_LONG=8"
$ export CPPFLAGS
```
Configure the unixODBC build system. For example:
```
$ ./configure --enable-gui=no --enable-drivers=no
```
For information about unixODBC configure options, see our Linux/UNIX ODBC article. In the example command, the options specify that unixODBC should be built without GUI components or sample ODBC drivers.

The default for the unixODBC 2.2.12 source distribution is to build 32-bit SQLLEN/SQLULEN types. However, this does not mean that a unixODBC 2.2.12 package included with a Linux or Unix distribution will be built with 32-bit SQLLEN/SQLULEN types too. For example, on RedHat, Debian and Ubuntu Linux distributions, the unixODBC package is built with 64-bit SQLLEN/SQLULEN types.

Applications that pass 64-bit values to SQLLEN/SQLULEN ODBC API parameters must be used with a version of unixODBC that is built with 64-bit SQLLEN/SQLULEN types (and vice versa). If unixODBC is built with 64-bit SQLLEN/SQLULEN types, it must be used with an ODBC driver that is built with 64-bit SQLLEN/SQLULEN types (and vice versa). If you are using a version of unixODBC that was included in an Easysoft ODBC driver distribution, both ODBC driver manager and ODBC driver will be built with the same size SQLLEN/SQLULEN types. However, the Easysoft driver installation script gives you the option to use the version of unixODBC included in the operating system distribution rather than the driver distribution. If an Easysoft ODBC driver built with 32-bit SQLLEN/SQLULEN types was used with a unixODBC driver manager built with SQLLEN/SQLULEN types, the results will be unpredictable. Side effects could include data loss/corruption or your application crashing.

For example, Oracle DG4ODBC passes 64-bit values to SQLLEN/SQLULEN ODBC API parameters, and therefore must be used with a 64-bit SQLLEN/SQLULEN ODBC driver manager and ODBC driver. To illustrate the potential side effects of not doing this, we used the following application/driver manager/driver combinations to retrieve NVARCHAR SQL Server data from the Northwind Suppliers table:

DG4ODBC/64-bit SQLxLEN ODBC Driver Manager/32-bit SQLxLEN SQL Server ODBC driver.
DG4ODBC/32-bit SQLxLEN ODBC Driver Manager/32-bit SQLxLEN SQL Server ODBC driver.

In both cases, we experienced data loss:

SQL> select "ContactName" from Suppliers@sqlsrv2005;

ContactName
------------------------------------------------------------
Charlotte Cooper
Shelley Burke
Regina Murphy
Yoshi Nagas
Antonio del V
Mayumi Ohno
Ian Devling
Peter Wilson
Lars Peterson
Carlos Diaz
Petra Winkler

ContactName
------------------------------------------------------------
Martin Bein
Sven Petersen
Elio Rossi
Beate Vileid








ContactName
------------------------------------------------------------








29 rows selected.

At the time of writing, applications that Easysoft know to have been built with 64-bit SQLLEN/SQLULEN types are:

DG4ODBC
IBM UniData 7.1.8+.
PHP (CentOS package).

unixODBC 2.2.13+

In unixODBC 2.2.13, the default size of SQLLEN/SQLULEN types changed from 32 bits to 64 bits. (The current release, 2.2.14, of the unixODBC source distribution is available on the Easysoft FTP site, ftp://ftp.easysoft.com/pub/unixODBC.) In unixODBC 2.2.13+, the BUILD_LEGACY_64_BIT_MODE and SIZEOF_LONG_INT macros in sqltypes.h control whether the SQLLEN/SQLULEN types are 32-bit or 64-bit (the default). To build unixODBC 2.2.13+ with 32-bit SQLLEN/SQLULEN types, use CPPFLAGS to define BUILD_LEGACY_64_BIT_MODE and SIZEOF_LONG_INT before configuring the unixODBC build system. For example:

$ CPPFLAGS="-DBUILD_LEGACY_64_BIT_MODE -DSIZEOF_LONG_INT=8"
$ export CPPFLAGS
$ ./configure --enable-gui=no --enable-drivers=no
$ make
$ cd exe
$ ./odbc_config --ulen
-DSIZEOF_SQLULEN=4

You can use unixODBC’s odbc_config program to display information about how unixODBC was built. The unixODBC 2.2.13+ version of odbc_config supports the --ulen option, which reports whether the unixODBC driver manager was built with 64-bit or 32-bit SQLLEN/SQLULEN types. If odbc_config --ulen displays -DSIZEOF_SQLULEN=8, unixODBC was built with 64-bit SQLLEN/SQLULEN types. If odbc_config --ulen displays -DSIZEOF_SQLULEN=4, unixODBC was built with 32-bit SQLLEN/SQLULEN types.

Note that not all unixODBC distributions include odbc_config. Note also that odbc_config only reports information about the unixODBC distribution it was shipped with. For example, you have two copies of unixODBC installed on a machine: one copy built from source, which includes odbc_config; one copy supplied with the operating system, which does not include odbc_config. The odbc_config program cannot be used to provide information about the operating system version of unixODBC.

Note The Easysoft ODBC-ODBC Bridge will currently not work with a version of unixODBC that is built with 64-bit SQLLEN/SQLULEN types. A version of the Easysoft ODBC-SQL Server Driver that supports 64-bit SQLLEN/SQLULEN types is available on request from the Easysoft support team (support@easysoft.com).

iODBC Driver Manager

iODBC is another ODBC driver manager that is available for Linux and Unix platforms (and Mac OS X and Windows). The default for the iODBC source distribution is to build the iODBC driver manager with 64-bit SQLLEN/SQLULEN types. These types were introduced in the 3.52.1 release of iODBC.

ODBC on 64-bit Windows Platforms

32-bit ODBC drivers are available to 32-bit applications running in the WOW64 layer, but not to 64-bit applications.

On 64-bit Windows platforms, there is both a 32-bit and a 64-bit version of ODBC Administrator. The 64-bit ODBC Administrator is located in the standard location: Administrative tools in Control Panel. The 64-bit version of the ODBC Administrator only lists 64-bit ODBC drivers and data sources.

To work with 32-bit ODBC driver data sources on 64-bit Windows, you need to use the 32-bit ODBC Administrator. To run the 32-bit version of the ODBC Administrator, in the Windows Run dialog box, type:

%windir%\syswow64\odbcad32.exe

User data sources are visible to both 32-bit and 64-bit applications. If a 64-bit application tries to use a User data source created in the 32-bit ODBC Administrator, it will find the data source but will only be able to load the ODBC driver if a 64-bit version is installed. The redirection mechanism in the WOW64 layer loads the 64-bit version of the ODBC driver (in %windir%\system32) rather than the 32-bit driver (in %windir%\syswow64) specified by the data source.

The last type of data source is the system data source. These are visible to all users that have the necessary access rights. These data sources are also will always refer to drivers with the same architecture (32-bit or 64-bit) as the client application. The reason for this is that they are stored in a registry key called HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI which is also redirected by the WOW64 to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI for 32-bit applications. So, if a 32-bit application (including the ODBC Data Source Administrator tool) installs a system data source it will only be visible to 32-bit applications. If a 64-bit application installs a system data source it will only be visible to 64-bit applications.

System data sources created in the 64-bit ODBC administrator are only visible to 64-bit applications. System data sources created in the 32-bit ODBC administrator are only visible to 32-bit applications. 32-bit driver data sources are stored in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI (which is only visible to 32-bit applications) rather than the standard location, HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI.

Accessing Oracle from 32-bit ODBC Applications on 64-bit Windows Platforms

The Easysoft ODBC-Oracle Driver accesses Oracle by using the Oracle database client, which uses Oracle Net to communicate with the database. Some versions of the Oracle Net software fail with the error ORA-12154: TNS:could not resolve the connect identifier specified if the application with which you are trying to connect is installed in a directory that contains parentheses in its name. This issue affects 32-bit applications on 64-bit Windows platforms because Windows installs 32-bit applications under the drive:\Program Files(x86) directory.

The Oracle bug report associated with this problem is Bug 3807408 Cannot Externally Authenticate User With Quote In Username (Oracle MetaLink login required).

To fix this problem and therefore enable 32-bit applications to access Oracle through ODBC/Oracle Net, obtain and apply an Oracle patch set from that contains a fix for bug 3807408.

If the patch is not available for your version of the Oracle client, you can try working around the problem by starting your application from the command prompt. In the command line, replace Program Files(x86); with Progra~2.

For more information about Oracle on 64-bit Windows issues and workarounds, see the MSDN forum posting Connecting to Oracle on 64-bit (x64) machines.

Frequently Asked Questions

Do I need to use a 32-bit or 64-bit ODBC driver?
How can I tell whether an application is 32-bit or 64-bit?
Can I use a 32-bit ODBC driver on 64-bit platforms?
My database is running on a 64-bit machine. Do I need to use a 64-bit ODBC driver to connect to it?

Do I need to use a 32-bit or 64-bit ODBC driver?

Whether you use a 32-bit or 64-bit ODBC driver depends on whether your application is 32-bit or 64-bit. A 64-bit ODBC driver can only be used with a 64-bit application. Similarly, a 32-bit ODBC driver can only be used with a 32-bit application.

64-bit applications must be linked against 64-bit libraries (known as shared objects on Unix and DLLs on Windows). For this reason, 64-bit applications can only link against a 64-bit ODBC Driver Manager shared object (or DLL). 64-bit ODBC Driver Managers can only load 64-ODBC drivers.

For the same reason, a 32-bit ODBC driver can only be used with a 32-bit application.

Note that it does not matter whether the database you are connecting to is 32-bit or 64-bit. Your choice of ODBC driver is dictated by the architecture of the client application not the database.

Examples

To connect	Use
A 64-bit version of IBM UniVerse/UniData to a SQL Server database.	A 64-bit SQL Server ODBC driver.
A 32-bit version of Oracle HS ODBC on a 64-bit platform to a SQL Server database.	A 32-bit SQL Server ODBC driver. 32-bit ODBC drivers function perfectly well on 64-bit systems.
A 32-bit version of Python to a 64-bit Oracle database.	A 32-bit Oracle ODBC driver.
A 64-bit version of PHP to an Access database running on a 64-bit Windows machine.	A 64-bit ODBC-ODBC Bridge client and a 32-bit ODBC-ODBC Bridge server.

How can I tell whether an application is 32-bit or 64-bit?

Because 32-bit and 64-bit applications can coexist on a 64-bit system, knowing whether your application platform architecture is 64-bit is not enough to determine whether an application is 64-bit or 32-bit. For example, IBM support Lotus Domino 7.x on 64-bit AIX, Solaris, Linux and Windows 2003 machines, even though Domino 7.x is a 32-bit application.

Similarly, just because your application was included in a 64-bit distribution does not necessarily mean that it is also 64-bit. For example, the HSODBC component included in 64-bit Oracle distributions is 32-bit.

On Unix systems, you can use the file command to tell whether an application is 32-bit or 64-bit. To do this, locate the application binary and then run file file. If the file is 64-bit, the command output will contain "ELF 64-bit" (or something similar such as "ELF-Class64" or "ELF-64"). If the file is 32-bit, the command output will contain "ELF 32-bit".

(To check whether Lotus Domino is 64-bit, you can also type sh stat server at the server console. The "Server.Version.Architecture" statistic shows you whether Domino is 64-bit.)

In this example, the file command’s output shows that PHP’s command line interface binary is 64-bit:

$ which php
/usr/bin/php
$ file /usr/bin/php
/usr/bin/php: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs),
for GNU/Linux 2.6.9, stripped

This application, therefore, needs to be used with a 64-bit ODBC Driver Manager/driver, which can also be verified with the file command. The unixODBC Driver Manager shared object is called libodbc.so. You can find out the name of the ODBC driver shared object by checking the entry for the driver in /etc/odbcinst.ini. Look at the Driver attribute value.

For example:

$ locate libodbc.so
/usr/local/easysoft/unixODBC/lib/libodbc.so
/usr/local/easysoft/unixODBC/lib/libodbc.so.1
/usr/local/lib/libodbc.so
/usr/local/lib/libodbc.so.1
$ file /usr/local/lib/libodbc.so
/usr/local/lib/libodbc.so: symbolic link to `libodbc.so.1.0.0'
$ file /usr/local/lib/libodbc.so.1.0.0
/usr/local/lib/libodbc.so.1.0.0: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), not stripped
$ more /etc/odbcinst.ini | grep Driver
Driver          = /usr/local/easysoft/oracle/libesoracle.so
Description     = Easysoft ODBC-Oracle Driver
$ file /usr/local/easysoft/oracle/libesoracle.so
/usr/local/easysoft/oracle/libesoracle.so: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), not stripped

In the example, the output from the locate command shows that there are two versions of unixODBC on this system. The version in /usr/local/easysoft was included in the ODBC driver distribution. Because the ODBC driver is 64-bit (as proven by running file), the driver manager supplied with it will always be 64-bit also.

Note Not all Unix platforms use ".so" as the shared object file extension. Some versions of HP-UX use ".sl". AIX uses archives (".a") containing shared objects using the ".o" extension.

In this next example, both components of a composite solution (PHP under Apache) are shown to be 64-bit:

$ which httpd
/usr/sbin/httpd
$ file /usr/sbin/httpd
/usr/sbin/httpd: ELF 64-bit LSB shared object, x86-64, 
version 1 (SYSV), for GNU/Linux 2.6.9, stripped
$ locate libphp5.so
/usr/lib64/httpd/modules/libphp5.so

Because the Apache HTTP Server binary is 64-bit, any Dynamic Shared Objects (DSOs) it needs to load must also be 64-bit. Because the DSO module for PHP is located under /usr/lib64, there is no need to use file to verify whether it is 64-bit. Only 64-bit libraries and object files are installed under directories called lib64.

On Windows, run the application and open Task Manager (right-click the taskbar, and then click Task Manager). If the application process has "*32" after its name, it is a 32-bit application. Otherwise, it is a 64-bit application.

Can I use a 32-bit ODBC driver on 64-bit platforms?

Yes. On 64-bit platforms, 32-bit ODBC drivers are available to 32-bit applications, but not to 64-bit applications. What determines your choice of ODBC driver architecture is whether your application is 32-bit or 64-bit not whether your client platform (or database platform or DBMS) is 32-bit or 64-bit.

For example, HSODBC is 32-bit even though it may have been included in a 64-bit Oracle distribution and installed on a 64-bit machine. (HSODBC is an Oracle component which uses ODBC to enable Oracle client applications to transparently access non-Oracle databases.) You therefore must use HSODBC with a 32-bit ODBC driver.

There may be both a 32-bit and a 64-bit ODBC driver available for your platform, but you must use the 32-bit driver if your application is 32-bit.

My database is running on a 64-bit machine. Do I need to use a 64-bit ODBC driver to connect to it?

No. The database platform architecture does not affect whether you need to use a 64-bit or a 32-bit ODBC driver. 64-bit database editions are compatible with 32-bit applications and support client access through a 32-bit ODBC driver without requiring any changes to application code. If your application is 64-bit, you must use a 64-bit ODBC driver regardless of database platform architecture.

Similarly, you can access a 32-bit database edition with either a 64-bit application/ODBC driver or a 32-bit application/ODBC driver.

Appendix A: Resources

Easysoft ODBC drivers:
- Oracle ODBC driver
- SQL Server ODBC driver
- Sybase ODBC driver
- InterBase ODBC driver
- Firebird ODBC driver
- C/D-ISAM ODBC driver
- LINC Developer ODBC driver
- System Z ODBC driver
- Tetra/CS3 ODBC driver
- ODBC-JDBC Gateway—providing ODBC access to JDBC data sources.
- ODBC-ODBC Bridge—providing ODBC access to any remote ODBC data source, for example, MS Access from Linux.
Linux/UNIX ODBC—everything you need to know about ODBC on Linux and UNIX platforms.
ODBC 64-Bit Information (Microsoft ODBC Programmer’s Reference)
An Introduction to 64-bit Computing and x86-64