http://www.unixodbc.org/

http://www.easysoft.com/developer/interfaces/odbc/linux.html

http://www.ibm.com/developerworks/cn/linux/database/odbc/index.html

 

 

login / register

 

Easysoft.com Documentation Knowledge Base

Products | Solutions | Support | Applications | Developer | Company  

Linux/UNIX ODBC

This document contains all the information you need to get started accessing ODBC data sources on Linux and UNIX platforms. The document provides background information about ODBC and its implementation on Linux and UNIX, describes the unixODBC ODBC Driver Manager in detail and lists some commonly used Linux/UNIX applications and interfaces that support ODBC.

 

Contents

Introduction

What is ODBC?

ODBC versions

Components of ODBC

What is the state of Linux ODBC?

ODBC Driver Managers

What does the ODBC Driver Manager do?

ODBC Drivers

ODBC Bridges and Gateways

ODBC-JDBC Gateways

JDBC-ODBC Bridges

The unixODBC ODBC Driver Manager

What is unixODBC?

Obtaining, Configuring and Building unixODBC

Obtaining unixODBC

Configuring and building unixODBC

Where are ODBC drivers defined?

How do you install an ODBC driver?

How do you create an ODBC data source

What are System and User data sources

Where are ODBC data sources defined?

What does a data source look like?

Testing DSN connections

isql beyond testing connections

Tracing ODBC calls

What does the cursor library do?

Setting ODBC driver environment variables automatically

UNICODE in unixODBC

ODBC support in applications and interfaces

ODBC abstraction libraries

libodbc++

C

Perl

PHP

Python

Rexx/SQL

Ruby

QT

OpenOffice.org

StarOffice

DG4ODBC

hsODBC

FreeRADIUS

IBM UniVerse/UniData

Lotus Notes/Domino

Micro Focus COBOL

mnoGoSearch

OpenLDAP

Snort

Delphi and Kylix

Appendix A: unixODBC ini files format

Appendix B: unixODBC installed files

Appendix C: Resources

Introduction

This document was written to help people understand ODBC on Linux and UNIX.

 

What is ODBC?

Open Database Connectivity (ODBC) is a standard software API specification for using database management systems (DBMS). ODBC is independent of programming language, database system and operating system.

 

ODBC was created by the SQL Access Group and first released in September, 1992. ODBC is based on the Call Level Interface (CLI) specifications from SQL, X/Open (now part of The Open Group), and the ISO/IEC.

 

The ODBC API is a library of ODBC functions that let ODBC-enabled applications connect to any database for which an ODBC driver is available, execute SQL statements, and retrieve results.

 

The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC achieves this by inserting a middle layer called a database driver between an application and the DBMS. This layer translates the application's data queries into commands that the DBMS understands.

 

ODBC Versions

 

There are (to date) 4 significant versions of ODBC:

 

Version Description

1.0 (c1993) The first version of ODBC. Only a few ODBC 1.0 applications and drivers still exist (on Windows) and none we know of on Linux.

2.0 (c1994)

The second version of ODBC. Small reorganisation of API (e.g. new SQLBindParameter replacing SQLSetParam) core, level 1 and 2 conformance changes, new data types.

 

There are still a number of ODBC 2.0 applications and drivers around. On Linux, most ODBC drivers are ODBC 3 and the few that are still ODBC 2.0 are generally moving to 3.

 

There was also an ODBC 2.5.

 

3.0 (c1995). ODBC 3.0 introduced a large number of new APIs and ODBC descriptor handles. Most ODBC drivers on Linux are now ODBC 3.0 and many applications are also 3.0.

3.5x (c1997). Introduction of UNICODE.

Components of ODBC

 

A basic implementation of ODBC on Linux is comprised of:

 

An ODBC compliant application i.e. an application which uses the ODBC API to talk to a DBMS.

The ODBC Driver Manager. The ODBC Driver Manager (see ODBC Driver Managers) is the link between an ODBC application and an ODBC driver. Applications requiring ODBC access link with the driver manager and make ODBC API calls which cause the driver manager to load the appropriate ODBC Driver. The ODBC Driver manager also provides other functions (see What does the ODBC Driver Manager do?).

A repository containing a list of installed ODBC drivers and defined ODBC data sources. The ODBC driver manager normally looks after these definitions and consults them when applications connect to a data source.

An ODBC driver. The ODBC driver translates ODBC API calls into something the backend DBMS understands.

However, ODBC also includes:

 

A cursor library (see What does the cursor library do?)

Utilities and APIs to install, remove and query installed drivers.

APIs for data sources to be configured/created/removed from an application (e.g. ConfigDSN etc).

Utility APIs an ODBC driver can use to handle the reading and writing of data source definitions (e.g. SQLGetPrivateProfileString).

A GUI and non-GUI ODBC Administrator.

All the header files required to build ODBC applications.

What is the state of Linux ODBC?

ODBC on Linux is in a healthy state today with many applications and interfaces having ODBC support and a wealth of available ODBC drivers.

 

The general goal of ODBC for Linux was to:

 

Replicate the ODBC functionality available on Windows so that application authors could write ODBC applications that worked on Windows and Linux/UNIX. This required the writing of an ODBC Driver Manager.

 

For the most part this has been achieved in unixODBC which provides a full ODBC 3.5 compatible driver manager including the full ODBC API, all the driver utility functions, installer, deinstaller and configuration library for ODBC drivers, a GUI administrator, an odbctest utility, the full development headers, a non-GUI administration utility (odbcinst) and a command line ODBC application to test data sources and issue SQL to the underlying ODBC driver.

 

Make available ODBC drivers on Linux. There are now a large number of commercial and Open Source drivers available for Linux/UNIX.

ODBC Driver Managers

There are two open source ODBC driver managers for UNIX (unixODBC and iODBC). This document describes the unixODBC Driver Manager as it is the one included with most (if not all) Linux distributions and some UNIX distributions.

 

What does the ODBC driver manager do?

 

The ODBC driver manager is the interface between an ODBC application and the ODBC driver. The driver manager principally provides the ODBC API so ODBC applications may link with a single shared object and be able to talk to a range of ODBC drivers. e.g. an application on Linux links with libodbc.so (the main driver manager shared object) without having to know at link time which ODBC driver it is going to be using. At run time the application provides a connection string which defines the ODBC data source it wants to connect to and this in turn defines the ODBC driver which will handle this data source. The driver manager loads the requested ODBC driver (with dlopen(3)) and passes all ODBC API calls on to the driver. In this way, an ODBC application can be built and distributed without knowing which ODBC driver it will be using.

 

However, this is a rather simplistic description of what the driver manager does. The ODBC driver manager also:

 

Controls a repository of installed ODBC drivers (on Linux this is the file odbcinst.ini).

Controls a repository of defined ODBC data sources (on Linux these are the files odbc.ini and .odbc.ini).

Provides the ODBC driver APIs (SQLGetPrivateProfileString and SQLWritePrivateProfileString) to read and write ODBC data source attributes.

Handles ConfigDSN which the driver exports to configure data sources.

Provides APIs to install and uninstall drivers (SQLInstallDriver).

Maps ODBC versions e.g. so an ODBC 2.0 application can work with an ODBC 3.0 driver and vice versa.

Maps ODBC states between different versions of ODBC.

Provides a cursor library for drivers which only support forward-only cursors.

Provides SQLDataSources and SQLDrivers so an application can find out what ODBC drivers are installed and what ODBC data sources are defined.

Provides an ODBC administrator which driver writers can use to install ODBC drivers and users can use to define ODBC data sources.

ODBC Drivers

An ODBC driver exports the ODBC API such that an ODBC application can communicate with a DBMS. Sometimes the ODBC driver is single tier where the driver accesses the files directly and sometimes the the driver is multi-tier where it communicates with the DBMS via another layer.

 

There are a large number of commercial and open source ODBC drivers available for Linux/UNIX. Easysoft have available a number of commercial ODBC drivers available for Linux including:

 

Oracle

SQL Server

Access

Sybase

Interbase

Firebird

C/D-ISAM

LINC Developer

System Z

OJG, providing ODBC access to JDBC data sources

OOB, providing ODBC access to any remote ODBC data source e.g. MS Access from Linux

dbExpress providing access to ODBC data sources from Borland's Kylix, Delphi and C++ Builder

In addition, you can find Open Source ODBC drivers for MySQL and Postgres.

 

 

 

ODBC Bridges and Gateways

An ODBC bridge or gateway provides an ODBC API at one end of the bridge/gateway and a different API at the other end. The most popular API people want to bridge to/from ODBC is JDBC.

 

ODBC-JDBC Gateways

 

An ODBC-JDBC gateway allows an application that uses the ODBC API to talk to a JDBC Driver:

 

application <-> ODBC API <-> JDBC API <-> database

An example of this is the Easysoft ODBC-JDBC Gateway.

 

You would typically use an ODBC-JDBC gateway if you had an existing application that used the ODBC API to access databases, and wanted to use that application to access a database for which there was no ODBC driver available, but a JDBC driver was available.

 

The ODBC calls your application makes are converted to JDBC calls and passed to the JDBC driver. As far as the JDBC driver is concerned, the ODBC driver is just another JDBC application. As far as the application is concerned, it is using a normal ODBC driver.

 

The ODBC-JDBC gateway is installed on the same machine as your application, and depending on how the gateway was written you:

 

Install Java and the JDBC driver on the same machine, and the gateway uses Java Native Interface (JNI) to load the JDBC driver classes.

Install a server process on the same machine as the database, Java and the JDBC driver. The gateway communicates over your network, converting ODBC calls at the client end through a proprietary interface, and connecting to the server process, which uses JDBC to communicate with the JDBC driver. (In this case, the server process is normally written in Java.)

The first of these configurations is the most popular, probably because:

 

It avoids any proprietary interfaces.

Java is available for most platforms.

Most JDBC drivers are capable of communication over a network anyway.

It avoids any extra services/processes.

Nothing has to be installed on the server/database machine.

What may influence your use of an ODBC-JDBC gateway is:

 

The required JDK version.

JDBC compatibility.

Compatibility with JDBC types (1—4).

Transparency.

Some compromises are nearly always inherent in translating the ODBC API to the JDBC API, but these are usually less than you might think, and a good gateway will be very transparent. A common misconception is that adding a bridge between your ODBC application and JDBC driver will introduce a lot of overhead, but you might be surprised at how quick a good gateway can be.

 

JDBC-ODBC Bridges

 

A JDBC-ODBC bridge is the opposite of an ODBC-JDBC one. A JDBC-ODBC bridge allows a Java application using JDBC to access an ODBC driver:

 

Java application <-> JDBC <-> ODBC driver <-> database

An example of this is the Easysoft JDBC-ODBC Bridge.

 

You would typically use a JDBC-ODBC bridge if you had an existing Java application that used the JDBC API, and wanted to access a database for which an ODBC driver was available, but a JDBC driver was not.

 

For instance, you may want to access an MS Access database from Java, but there is no Microsoft JDBC driver for MS Access.

 

The JDBC calls your application makes are converted to ODBC calls and passed to the ODBC driver. As far as the Java application is concerned, it is using a normal JDBC driver. As far as the database is concerned, it is being accessed via the normal ODBC driver.

 

Because ODBC drivers are always written in C (the ODBC API is a C interface), they are built for particular operating systems and architectures. As a result, the most flexible configuration is one where a server process is installed on the machine containing the ODBC driver, and the JDBC side of the bridge communicates with it over the network from the client side where the JDBC driver is installed. Obviously, at the Java application end, Java will already be in use, and so use of the JDBC client end driver at this side of the bridge is not a problem (in fact, some bridges offer zero installation JDBC access).

 

JDBC is inherently Unicode, and so a good JDBC-ODBC bridge will convert JDBC calls into the ODBC API wide functions (SQLxxxW) and request SQL_WCHAR characters from the database where they are available.

 

What may influence your use of a JDBC-ODBC Bridge is:

 

The type of JDBC driver offered. A type 3, client/server solution, allows Java applications and ODBC drivers to be on separate machines. Not all JDBC-ODBC bridges are like this.

Support for recent JDBC specifications, but still allowing backward compatibility.

Java 2 Platform Standard Edition (J2SE) compliancy certified by Sun Microsystems.

Support of Unicode. ODBC Unicode support is substantially different from JDBC, so this is often an omitted feature.

Remote serving of the JDBC driver — zero installation of JDBC driver.

Support for JDBC features even when the underlying ODBC driver does not provide similar support (e.g., multiple concurrent statements).

Transparency. The Java application should not know it is really talking to an ODBC driver.

The unixODBC ODBC Driver Manager

What is unixODBC?

 

unixODBC is a project created to provide ODBC on non-Windows platforms. It includes:

 

An ODBC driver manager which adheres to the ODBC specification and replicates all the functionality you may be used to in the MS Windows ODBC Driver Manager (see What does the ODBC Driver Manager do? and Components of ODBC).

A collection of open source ODBC drivers.

A number of ODBC applications that illustrate ODBC usage and provide useful functionality e.g. the GUI DataManager, odbctest and isql.

unixODBC is distributed with RedHat, Debian, Slackware, Ubuntu, Suse, CentOS and most of the other Linux distributions and is available as source code (see Obtaining unixODBC).

 

unixODBC is a mature Open Source product having made its first beta release in in January 1999, version 1.0.0 in May 1999 and there have been many release since. At the time of writing (October 2005) the current version of unixODBC is 2.2.12.

 

Obtaining, Configuring and Building unixODBC

 

Obtaining unixODBC

 

unixODBC's web site is at www.unixodbc.org. unixODBC also has a sourceforge project at sourceforge.net/projects/unixodbc. You can download RPMs and the source from either site and you can find the latest development release at ftp.easysoft.com/pub/unixODBC.

 

Note that all Easysoft ODBC drivers for Linux/UNIX come with unixODBC prebuilt.

 

Configuring and building unixODBC

 

The unixODBC source distribution is a gzipped tar file. Uncompress it and then untar the resultant file e.g.

 

gunzip unixODBC-2.2.12.tar.gz

tar -xvf unixODBC-2.2.12.tar

Change into the resultant directory and run:

 

./configure --help

which will list all the options configure accepts. The principle ones you need to pay attention to are:

 

Option Description

--prefix This defines where you want to install unixODBC. If you do not specify this it will default to /usr/local. If you do not want unixODBC all under a single directory you can use other configure options like --bindir, --sbindir etc for finer control.

--sysconfdir This defines where you want unixODBC configuration files to be stored. This defaults to <prefix>/etc. The configuration files affected are odbcinst.ini (where ODBC drivers are defined), the system odbc.ini (where system data sources are defined) and ODBCDataSources (where system file DSNs are stored).

--enable-gui The default is "yes" if QT is found. If you want to build the GUI ODBC Administrator, odbctest and DataManager set this to "yes" (e.g. --enable-gui=yes). You will need QT libraries and header files to build the GUI components (see later). You should probably also set --with-x.

--enable-threads The default is "yes" if thread-support is found on your machine. All modern Linuxes will have pthreads support in glibc so it is probably best to leave this to default.

--enable-readline The default is "yes" if libreadline and its headers are found on your machine. This principally only affects unixODBC isql program. If readline support is found then you can edit text entered at the SQL prompt in isql.

--enable-drivers The default is "yes". When enabled this will build all the ODBC drivers included with unixODBC. This includes MySQL, Postgres, MiniSQL and a text file driver.

--enable-iconv This defaults to "yes" if libiconv and its header files are found on your machine. If you build with iconv and access then unixODBC can do UNICODE translations.

If you enable the GUI components then configure will try and find QT, its libraries and header files. If you have installed QT in a single place you can provide a hint to configure by setting the environment QTDIR (or --with-qt-dir) to point to the top of the tree where QT is installed. If QT libraries and header files are installed in separate trees and not the default places like /usr/lib and /usr/include you can use --with-qt-includes=DIR and --with-qt-libraries=DIR.

 

Where are ODBC drivers defined?

 

In unixODBC ODBC drivers are defined in the odbcinst.ini file. The location of this file is a configure-time variable defined with --sysconfdir but is always the file odbcinst.ini in the --sysconfdir defined path. If unixODBC is already installed you can use unixODBC's odbcinst program to locate the odbcinst.ini file used to defined drivers:

 

$ odbcinst -j

unixODBC 2.2.7

DRIVERS............: /etc/odbcinst.ini

SYSTEM DATA SOURCES: /etc/odbc.ini

USER DATA SOURCES..: /home/auser/.odbc.ini

In this example drivers are defined in /etc/odbcinst.ini.

 

You can tell unixODBC to look in a different path (to that which it was configured) for the odbcinst.ini file and SYSTEM DSN file (odbc.ini) by defining and exporting the ODBCSYSINI environment variable.

 

If you are using the GUI ODBC Administrator (ODBCConfig) you can view data sources in User and System DSN tabs:

 

 

 

How do you create an ODBC data source

 

There are three main ways of defining an ODBC data source:

 

If your driver has a setup library (see your odbcinst.ini file) then you may be able to define a SYSTEM or USER data source using the unixODBC ODBC administrator. Start the ODBC administrator using ODBCConfig, select USER or SYSTEM, add, select the ODBC driver and click OK. You should be presented with a dialogue specific to the ODBC driver - fill in the fields and click on OK. e.g. with the Easysoft ODBC-ODBC Bridge driver you get a tabbed dialogue like:

 

 

Edit the SYSTEM or USER DSN ini file ( odbc.ini or .odbc.ini) and add a data source using the syntax:

    [ODBC_datasource_name}

    Driver = driver_name

    Description = description_of_data_source

    attribute1 = value

    .

    .

    attributen = value

 

where, ODBC_datasource_name is the name you want to assign to this data source, Driver is assigned the name of the driver (see odbcinst.ini file for installed drivers and "attributen = value" is the name of an attribute and its value that the ODBC driver needs. e.g. for the Easysoft ODBC-ODBC Bridge you might define

[my_datasource]

Driver = OOB

Description = description_of_data_source

ServerPort = myoobserver:8888

TargetDSN = mytargetdsn

LogonUser = server_username

LogonAuth = password_for_LogonUser

You need to check with the ODBC Driver you are using to see what attributes you need to define, but at a minimum you must specify the Driver attribute and it is always advisable to include the Description attribute.

Create a FileDSN. ODBCConfig does not yet handle file DSNs properly but you can still use them if they are manually created or produced using the SAVEFILE connection attribute to SQLDriverConnect. A file DSN definition is basically the same as above (in the user and system ini files) except it is a file containing a single data source and the data source is always named ODBC. e.g.

[ODBC]

Driver = OOB

Description = description_of_data_source

ServerPort = myoobserver:8888

TargetDSN = mytargetdsn

LogonUser = server_username

LogonAuth = password_for_LogonUser

Note that File DSNs may be stored anywhere as they are referenced by including in the connection string FileDSN=/path_to_file_dsn.

 

You can list user and system data sources with:

 

$ /usr/local/easysoft/unixODBC/bin/odbcinst  -q -s

[sqlserver]

[ODBCNINETWO]

[aix]

[bugs]

[ib7]

[ODBC_JDBC_SAMPLE]

[postgres]

[EASYSOFT_JOINENGINE1]

[SYBASEA]

 

 

How do you install an ODBC driver?

 

There are three methods of installing an ODBC driver under unixODBC:

 

You write a program which links with libodbcinst.so and calls SQLInstallDriver.

You create an ODBC driver template file and run odbcinst. e.g.

    odbcinst -f template_file -d -i

 

In this case your template file must contain the Driver and Description attributes at a minimum and optionally the Setup attribute e.g.

  [DRIVER_NAME]

  Description = description of the ODBC driver

  Driver = path_to_odbc_driver_shared_object

  Setup = path_to_driver_setup_shared_object

 

You directly edit your odbcinst.ini file and add the driver definition.

In the odbcinst.ini each driver definition begins with the driver name in square brackets. The driver name is followed by Driver and Setup attributes where Driver is the path to the ODBC driver shared object (exporting the ODBC API) and Setup is the path to the ODBC driver setup library (exporting the ConfigDriver and ConfigDSN APIs used to install/remove the driver and create/edit/delete data sources). Few ODBC drivers for UNIX have a setup dialogue.

 

You can list all installed ODBC drivers with:

 

$ /usr/local/easysoft/unixODBC/bin/odbcinst  -s -q

[sqlserver]

[ODBCNINETWO]

[aix]

[bugs]

[ib7]

[ODBC_JDBC_SAMPLE]

[postgres]

[EASYSOFT_JOINENGINE1]

[SYBASEA]

What are System and User data sources

 

SYSTEM data sources are those accessible by anyone on the machine which defines the data source. Typically, these are defined in some system defined location that everyone has read access to (e.g. /etc/odbc.ini). USER data sources are defined in a users home directory in the file (.odbc.ini) and are only readable by that user (dependent on the value of your umask at the time the file is created).

 

Whether you can access USER DSNs depends on the ODBC driver you are using and whether it is built with unixODBC support.

 

How your driver locates SYSTEM and USER DSNs depends on whether it was built to use SQLGetPrivateProfileString in unixODBC or not. Drivers which know about the unixODBC driver manager use the ODBC API SQLGetPrivateProfileString() to obtain DSN attributes. If a driver does this it does not matter where SYSTEM or USER DSNs are defined, as unixODBC knows where to look for them and what the format of the odbc.ini (or .odbc.ini) file is. If your driver does not have built in support which uses the SQLGetPrivateProfileString then:

 

It will not know where your ODBC data sources are defined.

It may not be capable of parsing the odbc.ini file format.

ODBC Drivers supporting the unixODBC Driver Manager link against libodbcinst.so and include odbcinstext.h. If you are an ODBC driver writer we strongly recommend you install unixODBC and build your driver with:

 

-I /path/include /

  -L/path/lib -l odbcinst

and include odbcinst.h.

 

Some Server applications that use ODBC do not support user credentials or change to the specified user so they run in the context that the server application was started in. In this case they cannot access USER DSNs since they are not running as the user in which the user DSN is defined. A common error with Apache is to define a user DSN in the .odbc.ini file in user FRED’s account then run Apache under the nobody account. Bridges like the Easysoft ODBC-ODBC Bridge require a logonuser and logonauth which require the server application to change to the specified user and hence they have access to that user's DSNs. If you are using an application which runs as a specific user and you want to use USER DSNs then you need to define the USER DSN in that user's account or use a SYSTEM DSN.

 

Where are ODBC data sources defined?

 

ODBC data sources are defined in two different files depending on whether they are a USER DSN or a SYSTEM DSN (see What are System And User data sources). USER DSNs are defined in the .odbc.ini file in the current user's HOME directory. SYSTEM DSNs are defined is some single path defined at compile time for unixODBC with --sysconfdir. You can locate this directory after unixODBC has been built with:

 

$ odbcinst -j

unixODBC 2.2.7

DRIVERS............: /etc/odbcinst.ini

SYSTEM DATA SOURCES: /etc/odbc.ini

USER DATA SOURCES..: /home/martin/.odbc.ini

In this case USER DSNs are defined in /home/martin/.odbc.ini because the user running the odbcinst command was martin and his home account is /home/martin.

 

If you need to define the directory where USER data sources are to be found (different to the default) you can define the environment variable ODBCINI to point to the required path then export it. e.g. Suppose your Apache server was running as user nobody and you did not want to put the USER DSNs in /home/nobody you could define the ODBCINI environment variable as /path and then export it and USER DSNs would be looked up in /path/.odbc.ini.

 

If you are using the GUI ODBC Administrator (ODBCConfig) you can view data sources in User and System DSN tabs:

 

 

 

What does a data source look like?

 

Generally speaking a DSN is comprised of a name and a list of attribute/value pairs. Usually these attributes are passed to the ODBC API SQLDriverConnect as a semicolon delimited string such as:

 

DSN=mydsn;attribute1=value;attribute2=value;attributen=value;

What a specific ODBC driver needs is dependent on that ODBC driver. Each ODBC driver should support a number of ODBC connection attributes which are passed to the ODBC API SQLDriverConnect. Any attributes which are not defined in the ODBC connection string may be looked up in any DSN defined in the ODBC connection string. e.g. Suppose your ODBC application calls SQLDriverConnect with the connection string "DSN=fred;" but it needs the name of a server where the database is located. Since the connection string does not contain the attribute this driver needs to locate the server (e.g. Server=xxxxx) the ODBC driver can look up the DSN "fred" and see if this defines a "Server" attribute.

 

Any driver supporting unixODBC will use SQLGetPrivateProfileString to lookup any attributes it needs using the DSN name as a key. Generally your ODBC application either passes all the attribute=value pairs in the connection string or it lets you choose a DSN from a list then calls SQLDriverConnect("DSN=mydsn;") and then the ODBC driver looks up the additional attributes in the DSN definition.

 

Each ODBC driver should define the attributes which it needs to connect to a particular database. e.g. For the Easysoft ODBC-0DBC Bridge each DSN must define at a minimum, TargetDSN, LogonUser, LogonAuth and ServerPort where ServerPort is the name of the server where the ODBC-ODBC Bridge Server is running and the port it is listening on, TargetDSN is the name of the SYSTEM DSN on the server machine you want to connect to and LogonUser/LogonAuth are a valid username/password to logon to the server machine.

 

For unixODBC, SYSTEM DSNs are defined in an odbc.ini in the system defined path and USER DSNs are defined the the current user's home directory (in a file called .odbc.ini). The format of this file is:

 

[DSN_NAME]

Driver = driver_name_defined_in_odbcinst.ini

attribute1 = value

attribute2 = value

.

.

attributen = value

Testing DSN connections

 

Once you have installed your ODBC driver and defined an ODBC data source you can test connection to it via unixODBC's isql utility. The format of isql's command line for testing connection is:

 

isql -v DSN_NAME db_username db_password

You should use the -v option because this causes isql to output any ODBC diagnostics if the connection fails. The db_username and db_password are optional but you must supply them if your ODBC driver requires a database username and password to login to the DBMS.

 

If isql successfully connects to your DSN it should display a banner and a "SQL>" prompt:

 

bash-2.05$ isql -v my_dsn username password

+---------------------------------------+

| Connected!                            |

|                                       |

| sql-statement                         |

| help [tablename]                      |

| quit                                  |

|                                       |

+---------------------------------------+

SQL>

If it fails to connect (and you specified -v) then any ODBC diagnostic from the ODBC driver explaining why it could not connect should be displayed.

 

$isql -v mysql_db username password

[unixODBC][MySQL][ODBC 3.51 Driver]

Access denied for user 'username'@'xxx.easysoft.local' (using password: YES)

[ISQL]ERROR: Could not SQLConnect

What this ODBC diagnostic says depends on the ODBC Driver and you should look up it in the documentation for your ODBC Driver.

 

Some errors may be reported by the unixODBC driver manager itself (if for instance it could not connect to the ODBC driver). An example is

 

$isql -v dsn_does_not_exist username

 password

[unixODBC][Driver Manager]

Data source name not found, and no default driver specified

[ISQL]ERROR: Could not SQLConnect

In this case unixODBC could not locate the DSN "dsn_does_not_exist" and hence could not load the ODBC driver. Common reasons for this error are:

 

The DSN "dsn_does_not_exist" does not exist in your USER or SYSTEM ini files.

The DSN "dsn_does_not_exist" does exist in a defined ini file but you have omitted the "Driver=xxx" attribute telling the unixODBC driver manager which ODBC driver to load.

The "Driver=/path_to_driver" in the odbcinst.ini file points to an invalid path, to a path to an executable where part of the path is not readable/searchable or to a file that is not loadable (executable).

The Driver=xxx entry points to a shared object which does not export the necessary ODBC API functions (you can test this with dltest included with unixODBC.

The ODBC driver defined by DRIVER=xxx in the odbcinst.ini file depends on other shared objects which are not on your dynamic linker search path. Run ldd on the driver shared object named by Driver= in the odbcinst.ini file and see what dependent shared objects cannot be found. If some cannot be found than you need to defined your LD_LIBRARY_PATH environment variable to define the paths to any dependent shared objects or add these paths to /etc/ld.so.conf and rerun ldconfig.

isql beyond testing connections

 

NOTE: Unless you are running isql in batch mode we strongly suggest you run isql with the -v (verbose) argument because that will show ODBC diagnostics on failed commands and other useful information. Any examples in this section assume isql was run with the -v argument unless stipulated otherwise.

 

In Testing DSN connections we saw how isql can be used to test connection to your data sources. isql can do quite a lot more. Once connected to you data source you are provided with an SQL prompt at which you can:

 

Enter SQL which is sent to the ODBC driver you are connected to

Obtain the result-set from an SQLTables call to return a list of tables in your database. Just enter "help" at the prompt.

Obtain the result-set from an SQLColumns call to return a list of column definitions in a table. Just enter "help TABLENAME".

Anything entered at the SQL prompt in isql which is not a recognised isql command (see above) is passed to the ODBC driver via the ODBC API's SQLPrepare then SQLExecute. If the SQLExecute fails (or returns SQL_SUCCESS_WITH_INFO), isql will use SQLError to obtain ODBC diagnostics. e.g.:

 

SQL> select * from table_does_not_exist

[S0002][unixODBC][Microsoft][ODBC SQL Server Driver][SQL Server]

Invalid object name 'table_does_not_exist'.

[37000][unixODBC][Microsoft][ODBC SQL Server Driver][SQL Server]

Statement(s) could not be prepared.

[ISQL]ERROR: Could not SQLExecute

SQL> 

If the SQLExecute for your SQL succeeds then isql will use SQLNumResultCols to ascertain if the SQL returned a result-set (e.g. you executed a select). If a result-set is found, it will be fetched and displayed using the any settings from the command line settings -d or -x (how to delimit columns), -w (output in HTML table), -c (column names on first row if -d/-x used) and -m (limit column display width).

 

After any SQL succeeds, isql will call SQLRowCount to see how many rows were affected. You should note that many ODBC drivers return -1 if the SQL was a result-set generating statement, otherwise this should be the number of rows inserted, deleted or updated.

 

As each command or SQL statement enterered at the prompt and terminated with a newline will be passed to the ODBC driver you can run isql with stdin redirected to a file containing SQL. e.g. Suppose you created the file myfile.sql containing:

 

create table test (a integer)

insert into test values (1)

insert into test values (2)

then you can use:

 

isql -v mydsn dbuser dbauth < myfile.sql

to execute multiple SQL commands in one go. Obviously, you can also redirect stdout.

 

Tracing ODBC calls

 

The unixODBC driver manager can write a trace of call ODBC calls made to a file. This can be a very useful debugging aid but it should be remembered that tracing will slow your application down. You enable tracing using one of the following methods:

 

Locate your odbcinst.ini file (see Where are ODBC drivers defined?) and add a section to this file like:

[ODBC]

TraceFile = /tmp/sql.log

Trace = Yes

You can use any file for the TraceFile argument and it does not need to pre-exist. The permissions on the odbcinst.ini may be such that you need to be the root user.

 

You can enable tracing and define the trace file using the ODBC Administrator (ODBCConfig).

 

 

Be careful when running ODBC applications as different users and tracing because most users will set their umask such that other users cannot write to newly created files. If user A enables tracing and connects to the driver manager the trace file will be created and then when user B uses the driver manager it is likely nothing is traced because user B does not have write permission to the trace file.

 

Trace files generally contain a log of every entry and exit to each ODBC API. e.g.

 

[ODBC][9155][SQLAllocHandle.c][345]

                Entry:

                        Handle Type = 2

                        Input Handle = 0x80899d0

[ODBC][9155][SQLAllocHandle.c][463]

                Exit:[SQL_SUCCESS]

                        Output Handle = 0x8089f60

The general form is:

 

[ODBC][Process ID][C source containing the ODBC API][source line number]

      Entry:

         argument 1 = value

         argument 2 = value

         argument n = value

[ODBC][Process ID][C source containing the ODBC API][source line number]

      Exit: [ODBC status]

            output argument 1 = value

            output argument 2 = value

            output argument n = value

With this tracing you can see:

 

Each ODBC API called and in what order.

The arguments provided to each ODBC API.

Any values returned by an ODBC API

The exist status of each ODBC API

If a serious error occurs which could be a problem in unixODBC you can see the line number in the unixODBC source file where the error was generated.

What does the cursor library do?

 

The cursor library is included in unixODBC for applications which require cursors (more than forward-only cursors) but the driver does not support any cursor other than forward-only. Whether the cursor library is used depends on:

 

How the application calls SQLSetConnectAttr for the attribute SQL_ODBC_CURSORS. The default (if SQLSetConnectAttr is not called to set the SQL_ODBC_CURSORS attribute) is SQL_CUR_USE_DRIVER which means to use cursors in the ODBC driver (if you need cursors and the driver does not support the one you require the application will fail). Other values for SQL_ODBC_CURSORS are SQL_CUR_USE_IF_NEEDED (which means the cursor library will be used if you attempt to use a cursor the driver does not support), SQL_CUR_USED_ODBC (which means to use the cursor library in unixODBC) and SQL_CUR_USE_DRIVER (see default).

Whether you bind result-set values. The cursor library does not work for fetching results via SQLGetData. It only works if you issue a query, bind the columns to variables with SQLBindCol then call SQLFetch.

The cursor library is a shared object called libodbccr.so which will exist in the lib subdirectory of wherever you set --prefix to when you build/configure unixODBC. When the cursor library is in use the normal ODBC entry points to the ODBC driver are replaced with entry points in the cursor library which then go on to call the same entry points in the ODBC driver but they apply extra processing to imitate the required cursor.

 

Setting ODBC driver environment variables automatically

 

DMEnvAttr/SQL_ATTR_UNIXODBC_ENVATTR

This is a setting for the data source in the odbc.ini file. This is used to set ODBC environment attributes. The form is:

 

    DMEnvAttr = ATTRIBUTE_NAME=value

 

and if VALUE might contain spaces:

 

    DMEnvAttr = ATTRIBUTE_NAME={value}

 

where ATTRIBUTE_NAME is the name of an ODBC environment attribute (e.g. SQL_ATTR_CONNECTION_POOLING).

 

unixODBC defines a new environment attribute for itself called SQL_ATTR_UNIXODBC_ENVATTR. If your driver needs some environment variables defined to run (e.g. ORACLE_HOME, DB2INSTANCE) you can set them via SQL_ATTR_UNIXODBC_ENVATTR like this:

 

    DMEnvAttr = SQL_ATTR_UNIXODBC_ENVATTR={envvar=value;envar=value}

 

e.g.

 

    DMEnvAttr =

      SQL_ATTR_UNIXODBC_ENVATTR=

       {ORACLE_HOME=/opt/OraHome} 

 

which sets the ORACLE_HOME environment variable to /opt/OraHome before loading the Oracle ODBC driver.

 

DMConnAttr and DMStmtAttr

These unixODBC specific data source attributes work like DMEnvAttr (above). The format is:

 

    DMConnAttr = CONNECTION_ATTRIBUTE=value

    DMStmtAttr = STATEMENT_ATTRIBUTE=value

 

where:

CONNECTION_ATTRIBUTE is the name of an ODBC connection attribute (e.g. SQL_ATTR_CONNECTION_TIMEOUT).

STATEMENT_ATTRIBUTE is the name of an ODBC statement attribute (e.g. SQL_ATTR_NOSCAN).

"value" is the value you want to set the attribute to. e.g. SQL_ATTR_CONNECTION_TIMEOUT=30 or SQL_ATTR_NOSCAN=SQL_NOSCAN_OFF.

e.g.

 

    DMConnAttr = SQL_ATTR_AUTOCOMMIT=SQL_AUTOCOMMIT_OFF

 

N.B.

If you prefix the attribute name with a '*' then this fixes the value of that attribute i.e. in any attempt by the application to set that attribute the value specified by the application will be ignored and unixODBC will replace the value with that specified in the DMxxxAttr.

 

UNICODE in unixODBC

 

 

 

ODBC support in applications and interfaces

ODBC abstraction libraries

 

libodbc++

 

You can find the libodbc++ library at http://libodbcxx.sourceforge.net/

C

 

ODBC from C Tutorial Part 1

Example-based introduction to using ODBC from C.

 

ODBC from C Tutorial Part 2 - Fetching Results

Binding result set columns, retrieving data from unbound columns and returning multiple rows of data.

 

Perl

 

Enabling ODBC support in Perl with Perl DBI and DBD::ODBC

Building Perl DBI, adding the DBD::ODBC module and using an Easysoft ODBC driver in your Perl scripts.

 

Perl DBI/DBD::ODBC Tutorial Part 1 - Drivers, Data Sources and Connection

Connecting to ODBC data sources from Perl.

 

Perl DBI/DBD::ODBC Tutorial Part 2 - Introduction to retrieving data from your database

Executing SQL queries from Perl and retrieving the results.

 

Perl DBI/DBD::ODBC Tutorial Part 3 - Connecting Perl on UNIX or Linux to Microsoft SQL Server

Accessing SQL Server from Perl. Tutorial and examples.

 

Perl DBI - Put Your Data On The Web

Using Perl CGI scripts to publish your data on the web.

 

Debugging Perl DBI

Avoid errors by following our Perl DBI best practises. Track down errors quickly by selectively logging your application's DBI activity with DBIx::Log4perl.

 

http://search.cpan.org/~mjevans/DBD-ODBC

Download the DBD::ODBC Perl module. DBD::ODBC is the ODBC driver for Perl DBI.

 

http://search.cpan.org/~mjevans/DBIx-Log4perl

Download the DBIx::Log4perl Perl module. DBIx::Log4perl lets you selectively log your application's DBI activity.

 

PHP

 

Enabling ODBC support in PHP under Apache

Connecting to ODBC data sources from Apache/PHP.

 

Accessing Microsoft SQL Server from PHP under Apache on UNIX or Linux

Accessing SQL Server from Apache/PHP.

 

Accessing ODBC Databases with PHP and PEAR DB

Connecting to ODBC data sources through PEAR DB.

 

Python

 

Connecting to ODBC Databases from Python with mxODBC

Connecting to ODBC data sources through the Python mxODBC module.

 

Connecting to ODBC Databases from Python with pyodbc

Connecting to ODBC data sources through the Python pyodbc module.

 

Rexx/SQL

 

Accessing ODBC Databases from Rexx by using the Rexx/SQL Interface

Connecting to ODBC data sources through the Rexx/SQL interface.

 

Ruby

 

How to Connect Ruby to SQL Server from Linux and Unix

Connecting Ruby and RoR to SQL Server.

 

QT

 

Using ODBC in QT

Accessing ODBC data sources from your QT programs. Includes QODBC code sample.

 

OpenOffice.org

 

Accessing ODBC Databases from OpenOffice.org

Connecting to ODBC data sources from OOo applications such as Base, Calc and Writer.

 

StarOffice

 

Accessing ODBC Databases from StarOffice 8

Connecting to ODBC data sources from StarOffice applications such as Base, Calc and Writer.

 

DG4ODBC

 

Accessing SQL Server from Oracle with Database Gateway for ODBC (DG4ODBC)

Transparent SQL access from an Oracle 10g/11g client to non-Oracle ODBC data sources such as SQL Server.

 

hsODBC

 

hsODBC/Oracle Heterogeneous Services

Transparent SQL access from an Oracle 8i/9i client to non-Oracle ODBC data sources.

 

FreeRADIUS

 

Storing FreeRADIUS Authorization Information in ODBC Databases

Using an ODBC data source as a FreeRADIUS server backend.

 

IBM UniVerse/UniData

 

Accessing ODBC Databases from IBM UniVerse/UniData

Accessing ODBC data sources from the IBM U2 data servers, UniVerse and UniData.

 

Lotus Notes/Domino

 

Accessing ODBC Databases from Lotus Notes/Domino

Using Domino Enterprise Connection Services (DECS) to enable Lotus Notes/Domino applications to access ODBC data sources.

 

Micro Focus COBOL

 

Accessing ODBC Databases from Micro Focus COBOL by using the Server Express OpenESQL Interface

Using the Server Express OpenESQL Interface to access ODBC data sources.

 

mnoGoSearch

 

Using ODBC Databases to Store mnoGoSearch Data

Store mnoGoSearch indexer information in any database for which an ODBC driver is available.

 

OpenLDAP

 

Using OpenLDAP with Microsoft SQL Server and Oracle Backend Databases

Exposing data in SQL Server and Oracle databases to LDAP client applications.

 

Snort

 

Accessing ODBC Data Sources from Snort

Logging intrusions and alerts to remote ODBC data sources.

 

Delphi and Kylix

 

Easysoft dbExpress-ODBC Gateway

The dbExpress-ODBC Gateway lets applications developed with Borland Kylix, Delphi or C++ Builder access any database for which an ODBC driver is available.

 

Appendix A: unixODBC ini files format

unixODBC uses 3 ini files:

 

odbcinst.ini - to define installed/registered drivers and where to find them

odbc.ini - to define ODBC data sources

any_file - file DSNs accessed via FILE=any_file in the connection string

In all files, the following rules apply:

 

a '#' or ';' character at the start of a line means the rest of the line is a comment and will be ignored. NOTE, '#' or ';' characters anywhere else on a line other than the first characters will be interpreted literally.

sections of an ini file begin with a string in square brackets [,].

In the odbcinst.ini file the section defining a driver begins with the driver name in [ ].

 

In the odbc.ini file the DSN name is placed in [ ].

 

In a file DSN the data source name is always ODBC, (in square brackets) and there can only be one in each file.

 

when specifying attributes

e.g. attribute_1 = value_1

 

the white space either side of the assignment operator ('=') is ignored but white space elsewhere is taken literally

 

e.g. attribute_1 = attribute 1 value

 

assigns the value "attribute 1 value" to attribute_1.

 

In general you should avoid using braces {, } unless your driver documentation tells you otherwise as an existing issue with unixODBC stops anything after a line containing {} from being seen.

Appendix B: unixODBC installed files

If you build unixODBC yourself from the source distribution and restrict the build to unixODBC itself and not any of the included drivers (--enable-drivers=no) the following files are installed:

 

libodbc.so - the ODBC driver manager

ODBC applications link to this to access ODBC drivers

 

libodbcinst.so - the ODBC driver manager library drivers link with to access the SQLGetPrivateProfileString and other driver APIs. Installers might also link to this library to use SQLInstallDriver APIs.

libodbccr.so - the ODBC cursor library

dltest - a binary to check for the existence of shared object entry points

isql - a small example ODBC application that can be use to run queries against your ODBC drivers.

ODBCConfig - a GUI application which can be used to install, edit, create, delete ODBC drivers and data sources.

odbcinst - a small binary which may be used to install, create and delete ODBC drivers and data sources. It can also return various unixODBC configuration details e.g. version.

Various C header files:

odbcinstext.h odbcinst.h sqlext.h sql.h sqltypes.h sqlucode.h

 

NOTE: not all UNIX platforms use ".so" as the shared object file extension. Some versions of HP-UX use ".sl" and AIX uses archives (".a") containing shared objects using the ".o" extension.

 

Appendix C: Resources

64-bit ODBC -- everything you need to know about ODBC on 64-bit Linux, UNIX and Windows platforms.

Easysoft Guide to ODBC Diagnostics & Error Status Codes

The Easysoft web site

Article Feedback

 

* Did this content help you?

Yes

No

Maybe

 

* Please select one option based on your first choice:

I'm very satisfied

I think it will help, but I haven't tried it yet

It is helpful, but I need more information

It is helpful, but hard to understand

Seemed relevant in search results, but didn't help me

The information is incorrect

The page contains one or more broken links

 

  Suggest new content or let us know how we can improve this content:

 

 

  (* Required Fields)

 

 

 

? 1993 - 2010 Easysoft Limited. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other trademarks and registered trademarks appearing on easysoft.com are the property of their respective owners.

About Easysoft Contact Us Legal Search Help

 

 

 

 

 

 

 

    中国 [选择]     使用条款

 

 

 

 

   

     首页     产品     服务与解决方案     支持与下载     个性化服务    

 

developerWorks

中国

本文内容包括：

ODBC原理

Linux/Unix下ODBC的安装

Linux/Unix下ODBC的配置

Linux/Unix下ODBC的编程

参考资料

关于作者

对本文的评价

 

相关链接：

Linux 技术文档库

 

 

developerWorks 中国  >  Linux  >

Linux/Unix下ODBC的安装、配置与编程

文档选项

打印本页

将此页作为电子邮件发送

 

级别： 初级

齐亮 (cavendish@eyou.com), 

2002 年 7 月 01 日

本文主要内容是介绍ODBC的简单原理，以及如何在Linux/Unix下进行ODBC的安装、配置与编程。

ODBC原理

ODBC 是Open Database Connect 即开放数据库互连的简称，它是由Microsoft 公司于1991 年提出的一个用于访问数据库的统一界面标准，是应用程序和数据库系统之间的中间件。它通过使用相应应用平台上和所需数据库对应的驱动程序与应用程序的交互来实现对数据库的操作，避免了在应用程序中直接调用与数据库相关的操作，从而提供了数据库的独立性。

ODBC 主要由驱动程序和驱动程序管理器组成。驱动程序是一个用以支持ODBC 函数调用的模块，每个驱动程序对应于相应的数据库，当应用程序从基于一个数据库系统移植到另一个时，只需更改应用程序中由ODBC 管理程序设定的与相应数据库系统对应的别名即可。驱动程序管理器可链接到所有ODBC 应用程序中，它负责管理应用程序中ODBC 函数与DLL 中函数的绑定。

ODBC 使用层次的方法来管理数据库，在数据库通信结构的每一层，对可能出现依赖数据库产品自身特性的地方，ODBC 都引入一个公共接口以解决潜在的不一致性，从而很好地解决了基于数据库系统应用程序的相对独立性，这也是ODBC 一经推出就获得巨大成功的重要原因之一。

从结构上分，ODBC 分为单束式和多束式两类。

单束式驱动程序 

单束式驱动程序介于应用程序和数据库之间，像中介驱动程序一样数据提供一个统一的数据访问方式。 当用户进行数据库操作时，应用程序传递一个ODBC 函数调用给ODBC 驱动程序管理器，由ODBC API 判断该调用是由它直接处理并将结果返回还是送交驱动程序执行并将结果返回。 由上可见，单束式驱动程序本身是一个数据库引擎，由它直接可完成对数据库的操作，尽管该数据库可能位于网络的任何地方。

多束式驱动程序 

多束式驱动程序负责在数据库引擎和客户应用程序之间传送命令和数据，它本身并不执行数据处理操作而用于远程操作的网络通信协议的一个界面。 前端应用程序提出对数据库处理的请求，该请求转给ODBC 驱动程序管理器，驱动程序管理器依据请求的情况，就地完成或传给多束驱动程序，多束式驱动程序将请求翻译为特定厂家的数据库通信接口（如Oracle 的SQLNet）所能理解的形式并交于接口去处理，接口把请求经网络传送给服务器上的数据引擎，服务器处理完后把结果发回给数据库通信接口，数据库接口将结果传给多束式ODBC 驱动程序，再由驱动程序将结果传给应用程序。

很多程序员已经体会到了在Windows平台下的ODBC的益处，而在Linux/Unix下进行数据库编程的时候却不得不根据不同的数据库来选择特有的API进行编程，一旦数据库发生了改变，所有与这些API相关的程序都必须进行修改。其实在Linux/Unix下现在也有了自己的ODBC，可以使我们的数据库编程就像在Windows平台下一样简单。

下面我们开始介绍Linux/Unix下的ODBC：

 

 

 

 

 

回页首

 

 

Linux/Unix下ODBC的安装

方法一： 

先下载最新的unixODBC源码包（ http://www.unixodbc.org/unixODBC-2.2.1.tar.gz）放到/usr/local下，然后运行下述命令：

tar zxvf unixODBC-2.2.1.tar.gz

cd unixODBC-2.2.1 

./configure --prefix=/usr/local/unixODBC-2.2.1 --includedir=/usr/include --libdir=/usr/lib -bindir=/usr/bin --sysconfdir=/etc

make

make install

 

安装成功后，unixODBC所需的头文件都被安装到了/usr/inlucde下，编译好的库文件安装到了/usr/lib下，与unixODBC相关的可执行文件安装到了/usr/bin下，配置文件放到了/etc下。

方法二： 

下载rpm包进行安装，我们这里以Red Hat 7.3为例： 

unixODBC-2.2.0-5 RPM for i386（安装包及源码包） 

（ ftp://speakeasy.rpmfind.net/linux/redhat/7.3/en/os/i386/RedHat/RPMS/unixODBC-2.2.0-5.i386.rpm、 ftp://ftp.rpmfind.net/linux/redhat/7.3/en/os/i386/SRPMS/unixODBC-2.2.0-5.src.rpm） 

unixODBC-devel-2.2.0-5 RPM for i386 

（ ftp://speakeasy.rpmfind.net/linux/redhat/7.3/en/os/i386/RedHat/RPMS/unixODBC-devel-2.2.0-5.i386.rpm） 

直接将unixODBC-2.2.0-5.i386.rpm和unixODBC-devel-2.2.0-5.i386.rpm装入系统就可以了，命令如下：

rpm -ivh unixODBC-2.2.0-5.i386.rpm

rpm -ivh unixODBC-devel-2.2.0-5.i386.rpm

 

安装好以后，所需的各个部分与上面所列的位置相同。

 

 

 

 

 

回页首

 

 

Linux/Unix下ODBC的配置

运行ODBCConfig程序（在/usr/bin下），如下图：

 

图一：ODBCConfig主窗口

 

和Windows下的ODBC设置窗口是不是很像？我想大家都能看懂吧。

第一步：安装数据库的ODBC驱动程序 

Drivers这一栏中用来设置数据库的驱动程序，点击Add按钮，会出现下图：

 

图二：ODBCConfig Driver Properties窗口

 

Name一栏填入数据库驱动的名称，Description是数据库驱动的描述，Driver是用来选择数据库驱动程序的，Setup是用来选择数据库驱动安装程序的，如果你是按照上述安装方法安装的，这些程序都放在/usr/lib下，下面是数据库驱动程序的列表：

数据库 数据库驱动程序 数据库驱动安装程序

TXT libodbctxt.so libodbctxtS.so

NNTP libnn.so libodbcnnS.so

MiniSQL libodbcmini.so libodbcminiS.so

PostgreSQL libodbcpsql.so libodbcpsqlS.so

MySQL （注释） libodbcmyS.so

Sybase/MS SQL （注释） libtdsS.so

Oracle （注释） liboraodbcS.so

注释： 

MySQL、Sybase/MS SQL和Oracle的数据库驱动可以在下列网址找到： 

MySQL　　　　　　　　　　 http://www.unixodbc.org/myodbc.html 

Sybase/MS SQL　　　　　　 http://www.freetds.org 

Oracle　　　　　　　　　　 http://www.easysoft.org

MySQL的驱动程序MyODBC-2.50.39-4 RPM for i386以及源码包： 

ftp://speakeasy.rpmfind.net/linux/redhat/7.3/en/os/i386/RedHat/RPMS/MyODBC-2.50.39-4.i386.rpm 

ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/SRPMS/MyODBC-2.50.39-4.src.rpm

选择好驱动程序之后，点击"√"保存退出。

第二步：设置DSN 

DSN分为User DSN、System DSN和File DSN三种，我们以System DSN为例。选中System DSN一栏以后，点击Add…按钮就会见到下图：

 

图三：创建DSN选择数据库驱动

 

列表中会列出你已经安装好的数据库驱动程序，我这里只装了MySQL和PostgreSQL，然后选择你所要使用的驱动程序，然后点击OK就会出现下图：

 

图四：DSN的设置

 

我这里使用的是MySQL的数据库驱动，不同的数据库，这个窗口的内容会有所不同。Name是数据源的名称，Description是描述，Server可以选择服务器，如果本机启动了MySQL就可以选择localhost，如果Port和Socket有特殊要求，再根据实际情况进行修改，Database是用来选择数据库的，下拉菜单不一定包含所有的数据库，你可以把自己已经创建好的数据库名称填写在这里。都配置好之后，点击"√"保存退出。

这样Linux/Unix下的ODBC数据源就已经设置好了，大家还可以在ODBCConfig程序的Status栏中查看ODBC的使用情况，在Advanced栏中设置是否做日志或者启动连接池，在About栏中，有一个Linux/Unix ODBC的示意图，在Credits按钮中可以看到所有开发者的名字的列表。 ODBCConfig程序中所有有关数据库驱动程序的信息被放在odbcinst.ini（在/etc下）文件中，有关DSN的信息被放在odbc.ini（在/etc下）文件中，大家有兴趣的话，可以自己去观察一下。

第三步：使用DataManager程序浏览数据库 

运行DataManager程序之后就可以查看Drivers、System DSN和User DSN这几项内容，，在浏览数据库的时候，可以在右面的SQL栏中输入SQL语句，然后点击人形按钮就可以运行SQL语句，运行结果会在Results一栏中显示出来，具体情况可以见下图：

 

图五：使用DataManager浏览数据库

 

第四步：使用isql程序查看数据库 

unixODBC还提供了命令台下查看数据库的程序，这就是isql，用法如下：

isql DSN [UID [PWD]] [options]

DSN 数据源名称

UID 用户ID

PWD 用户密码

Options：

-b 批处理，没有提示符的模式

-dx 设置列之间的分隔符为x

-w 将查询结果输出为HTML格式

-c 第一行输出列名

--version           输出isql的版本号

 

 

 

 

 

回页首

 

 

Linux/Unix下ODBC的编程

1、使用unixODBC提供的ODBC API进行编程： 

在进行编程之前，我们来看一下ODBC API中的常用数据类型与我们在C语言中使用的数据类型的对应关系：

类型标识符 ODBC数据类型 C数据类型

SQL_C_CHAR SQLCHAR * unsigned char *

SQL_C_SSHORT SQLSMALLINT short int

SQL_C_USHORT SQLUSMALLINT unsigned short int

SQL_C_SLONG SQLINTEGER long int

SQL_C_FLOAT SQLREAL float

SQL_C_DOUBLE SQLDOUBLE, SQLFLOAT double

SQL_C_BINARY SQLCHAR * unsigned char *

SQL_C_TYPE_DATE SQL_DATE_STRUCT struct tagDATE_STRUCT {SQLSMALLINT year; SQLUSMALLINT month; SQLUSMALLINT day; } DATE_STRUCT;

SQL_C_TYPE_TIME SQL_TIME_STRUCT struct tagTIME_STRUCT {SQLUSMALLINT hour; SQLUSMALLINT minute; SQLUSMALLINT second; } TIME_STRUCT;

我们这里使用的数据库名称为test（DSN），这个DSN使用的用户名是root，密码为空，表的名称是web，字段情况如下：

字段名 数据类型

id integer

name char(40)

size integer

第一：设定ODBC环境句柄并设置参数 

首先我们需要声明一个ODBC环境句柄（SQLHENV），它可以用来获得有关的ODBC环境信息，我们需要调用SQLAllocHandle ( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &V_OD_Env )来获得这个句柄，V_OD_Env就是要分配的SQLHENV类型的环境句柄。 分配好句柄之后，你给它需要设定所使用的ODBC版本，你可以调用SQLSetEnvAttr ( V_OD_Env, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0 )，SQL_ATTR_ODBC_VERSION是存放你定义的ODBC版本号的变量，SQL_OV_ODBC3则说明你的程序使用的是ODBC 3.0。

第二：设定连接句柄并设置超时参数 

我们需要声明一个连接句柄（SQLHDBC），用来存放数据库连接信息的，调用SQLAllocHandle ( SQL_HANDLE_DBC, V_OD_Env, &V_OD_hdbc )获得连接句柄，V_OD_hdbc就是要分配的SQLHDBC类型的连接句柄。 分配好之后，我们可以调用SQLSetConnectAttr ( V_OD_hdbc, SQL_LOGIN_TIMEOUT, (SQLPOINTER *)5, 0 )来设定连接超时参数。

第三：连接数据库 

调用SQLConnect ( V_OD_hdbc, (SQLCHAR*) "Test", SQL_NTS, (SQLCHAR*) "root", SQL_NTS, (SQLCHAR*) "", SQL_NTS )连接我前面提到的数据库，需要设定三个参数，就是数据库名称、用户名和密码（因为我的数据库密码为空，所以这里的密码也为空），后面的SQL_NTS的位置应该写入这些参数的长度，如果写的是SQL_NTS就是让SQLConnect来决定参数的长度。

第四：分配SQL语句的句柄并进行查询： 

需要声明一个SQL语句的句柄（SQLHSTMT），用来存放SQL语句信息的，调用SQLAllocHandle ( SQL_HANDLE_STMT, V_OD_hdbc, &V_OD_hstmt )来获得这个句柄，V_OD_hstmt就是我们要分配的SQLHSTMT类型的SQL语句句柄。

我们的查询语句是：

SELECT name, id FROM web ORDER BY id

 

执行这条查询语句之后，查询结果可能有很多行，但每行只有两列，分别对应name和id，它们的数据类型为integer和char*，在ODBC中的数据类型标识符为SQL_C_ULONG和SQL_C_CHAR。我们需要先声明这样的两个变量来存贮查询结果：

SQLINTEGER V_OD_id;

char V_OD_buffer[200];

 

然后我们需要使用SQLBindCol函数把查询结果和我们定义的变量进行绑定：

SQLBindCol(V_OD_hstmt,1,SQL_C_CHAR, &V_OD_buffer,150,&V_OD_err);

SQLBindCol(V_OD_hstmt,2,SQL_C_ULONG,&V_OD_id,150,&V_OD_err);

 

这里的V_OD_err是用来存放错误信息编号的变量，类型也是SQLINTEGER。 

接下来，我们调用SQLExecDirect来进行查询：

SQLExecDirect ( V_OD_hstmt, "SELECT dtname,iduser FROM web order by iduser", SQL_NTS );

 

我们可以用SQLNumResultCols ( V_OD_hstmt, &V_OD_colanz )来获得结果的列数，也可以用SQLRowCount( V_OD_hstmt, &V_OD_rowanz )来获得结果的条数，V_OD_colanz和V_OD_rowanz分别存储相应的结果，类型分别为SQLSMALLINT和SQLINTEGER。 

在读取结果之前，我们需要调用SQLFetch ( V_OD_hstmt )语句，这个语句可以用来获得第一条结果也可以用来都下一条，有点像next的感觉。然后我们就可以在V_OD_id和V_OD_buffer里面获得每条记录的结果了。

第五：关于关闭连接和释放句柄 

关闭数据库的连接，调用SQLDisconnect ( V_OD_hdbc )就可以了，但在关闭数据库之前需要先释放SQL语句的句柄，而且在关闭数据库之后应该释放连接句柄和ODBC环境句柄，语句如下（按正常的顺序）：

SQLFreeHandle(SQL_HANDLE_STMT,V_OD_hstmt);

SQLDisconnect(V_OD_hdbc);

SQLFreeHandle(SQL_HANDLE_DBC,V_OD_hdbc);

SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

 

第六：关于上述情况中的错误信息处理 

我们需要定义两个变量：

long V_OD_erg;

SQLINTEGER V_OD_err;

 

SQLAllocHandle、SQLSetEnvAttr、SQLSetConnectAttr、SQLConnect、SQLExecDirect、SQLNumResultCols和SQLRowCount的调用结果都可以用V_OD_erg来存储，V_OD_err可以获得SQLBindCol中的错误信息。

第七：获得本机的DSN信息 

我们可以在声明SQLHENV句柄之后，使用SQLDataSources函数来获得本机的DSN信息。程序如下：

void OD_ListDSN(void)

{

char       l_dsn[100],l_desc[100];

short int  l_len1,l_len2,l_next;

l_next=SQL_FETCH_FIRST;

while( SQLDataSources(V_OD_Env,l_next,l_dsn, sizeof(l_dsn),

&l_len1, l_desc, sizeof(l_desc), &l_len2) == SQL_SUCCESS)

{

printf("Server=(%s) Beschreibung=(%s)/n",l_dsn,l_desc);

l_next=SQL_FETCH_NEXT;

}

}

 

l_next变量是用来指定我们所要获得的DSN的类别：

SQL_FETCH_FIRST 设定SQLDataSources()函数找到第一个可用的数据源（可以是User DSN，也可以是Systerm DSN）

SQL_FETCH_FIRST_USER 设定SQLDataSources()函数找到第一个User DSN

SQL_FETCH_FIRST_SYSTEM 设定SQLDataSources()函数找到第一个System DSN

SQL_FETCH_NEXT 找到下一个数据源，至于数据源类型则要根据前面的定义

到这里，我们在Unix的C语言下面进行ODBC编程已经讲完，上述ODBC API需要引用以下几个头文件（这些文件已经安装到/usr/include下了）：

#include <sql.h>

#include <sqlext.h>

#include <sqltypes.h>

 

另外如果大家使用GTK进行编程，由于到目前为止GTK还没有加入专门处理数据库的部件，所以大家可以在GTK中调用上述的ODBC API即可。

这里附上例程供大家参考学习：

/* odbc.c

    testing unixODBC

*/

#include <stdlib.h>

#include <stdio.h>

#include <odbc/sql.h>

#include <odbc/sqlext.h>

#include <odbc/sqltypes.h>

SQLHENV V_OD_Env; // Handle ODBC environment

long V_OD_erg; // result of functions

SQLHDBC V_OD_hdbc; // Handle connection

char V_OD_stat[10]; // Status SQL

SQLINTEGER V_OD_err,V_OD_rowanz,V_OD_id;

SQLSMALLINT V_OD_mlen,V_OD_colanz;

char             V_OD_msg[200],V_OD_buffer[200];

int main(int argc,char *argv[])

{

// 1. allocate Environment handle and register version 

V_OD_erg=SQLAllocHandle(SQL_HANDLE_ENV,SQL_NULL_HANDLE,&V_OD_Env);

if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

{

printf("Error AllocHandle/n");

exit(0);

}

V_OD_erg=SQLSetEnvAttr(V_OD_Env, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0); 

if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

{

printf("Error SetEnv/n");

SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

exit(0);

}

// 2. allocate connection handle, set timeout

V_OD_erg = SQLAllocHandle(SQL_HANDLE_DBC, V_OD_Env, &V_OD_hdbc); 

if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

{

printf("Error AllocHDB %d/n",V_OD_erg);

SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

exit(0);

}

SQLSetConnectAttr(V_OD_hdbc, SQL_LOGIN_TIMEOUT, (SQLPOINTER *)5, 0);

// 3. Connect to the datasource "web" 

V_OD_erg = SQLConnect(V_OD_hdbc, (SQLCHAR*) "Test", SQL_NTS,

                                     (SQLCHAR*) "root", SQL_NTS,

                                     (SQLCHAR*) "", SQL_NTS);

if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

{

printf("Error SQLConnect %d/n",V_OD_erg);

SQLGetDiagRec(SQL_HANDLE_DBC, V_OD_hdbc,1, 

             V_OD_stat, &V_OD_err,V_OD_msg,100,&V_OD_mlen);

printf("%s (%d)/n",V_OD_msg,V_OD_err);

SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

exit(0);

}

printf("Connected !/n");

V_OD_erg=SQLAllocHandle(SQL_HANDLE_STMT, V_OD_hdbc, &V_OD_hstmt);

if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

{

printf("Fehler im AllocStatement %d/n",V_OD_erg);

SQLGetDiagRec(SQL_HANDLE_DBC, V_OD_hdbc,1, V_OD_stat,&V_OD_err,V_OD_msg,100,&V_OD_mlen);

printf("%s (%d)/n",V_OD_msg,V_OD_err);

SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

exit(0);

}

    SQLBindCol(V_OD_hstmt,1,SQL_C_CHAR, &V_OD_buffer,150,&V_OD_err);

    SQLBindCol(V_OD_hstmt,2,SQL_C_ULONG,&V_OD_id,150,&V_OD_err);

    V_OD_erg=SQLExecDirect(V_OD_hstmt,"SELECT dtname,iduser FROM web order by iduser",SQL_NTS);   

    if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

    {

       printf("Error in Select %d/n",V_OD_erg);

       SQLGetDiagRec(SQL_HANDLE_DBC, V_OD_hdbc,1, V_OD_stat,&V_OD_err,V_OD_msg,100,&V_OD_mlen);

       printf("%s (%d)/n",V_OD_msg,V_OD_err);

       SQLFreeHandle(SQL_HANDLE_STMT,V_OD_hstmt);

       SQLFreeHandle(SQL_HANDLE_DBC,V_OD_hdbc);

       SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

       exit(0);

    }

    V_OD_erg=SQLNumResultCols(V_OD_hstmt,&V_OD_colanz);

    if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

    {

        SQLFreeHandle(SQL_HANDLE_STMT,V_OD_hstmt);

        SQLDisconnect(V_OD_hdbc);

        SQLFreeHandle(SQL_HANDLE_DBC,V_OD_hdbc);

        SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

        exit(0);

    }

    printf("Number of Columns %d/n",V_OD_colanz);

    V_OD_erg=SQLRowCount(V_OD_hstmt,&V_OD_rowanz);

    if ((V_OD_erg != SQL_SUCCESS) && (V_OD_erg != SQL_SUCCESS_WITH_INFO))

    {

      printf("Number of RowCount %d/n",V_OD_erg);

      SQLFreeHandle(SQL_HANDLE_STMT,V_OD_hstmt);

      SQLDisconnect(V_OD_hdbc);

      SQLFreeHandle(SQL_HANDLE_DBC,V_OD_hdbc);

      SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

      exit(0);

    }

    printf("Number of Rows %d/n",V_OD_rowanz);

    V_OD_erg=SQLFetch(V_OD_hstmt);  

    while(V_OD_erg != SQL_NO_DATA)

    {

     printf("Result: %d %s/n",V_OD_id,V_OD_buffer);

     V_OD_erg=SQLFetch(V_OD_hstmt);  

    }  ;

    SQLFreeHandle(SQL_HANDLE_STMT,V_OD_hstmt);

    SQLDisconnect(V_OD_hdbc);

    SQLFreeHandle(SQL_HANDLE_DBC,V_OD_hdbc);

    SQLFreeHandle(SQL_HANDLE_ENV, V_OD_Env);

    return(0);

}

 

2．QT下进行ODBC编程 

QT 3.0提供了Data Table、Data Browser和Data View三个与数据库相关的控件。你可以在QT的Project设置你要连接的数据库，Driver一栏中选择QODBC3即可，其它选项你一看就明白了。上述的三个数据库控件的使用方法可以参见QT中相应文档，也很好使用的。

 

 

参考资料

微软的ODBC主页： http://www.microsoft.com/data/odbc/；

UnixODBC的主页： http://www.unixodbc.org；

FreeODBC的主页： http://www.jepstone.net/FreeODBC/；

EasySoft的主页： http://www.easysoft.com；

TrollTech的QT 3.0文档主页： http://doc.trolltech.com/3.0/。

 

 

关于作者

 

齐亮，有幸于2001年参与Happy Linux 3.0的研发工作，对Linux情有独钟，现在从事Linux/Windows跨平台应用的开发，欢迎您通过电子邮件 cavendish@eyou.com跟他联系，希望能与更多的朋友交流关于Linux方面的知识。

 

 

 

 

 

 

You will need the following:

Linux ( I’m running RedHat 9.0)

PHP

Apache

UnixODBC

MDBTools

 

INSTRUCTIONS

1) Download the UnixODBC RPM, found here. I installed unixODBC version 2.2.5.1.

 

rpm -ivh unixODBC-2-2.5-1.i386.rpm

2) Download the MDBTools rpm, found here. I installed mdbtools version 0.5.1. Read limitations!

 

rpm -ivh mdvtools-0.5-1.i386.rpm

3) Download the MDBTools ODBC driver rpm. Again I installed version 0.5-1.i386.rpm. Read limitations!

 

rpm -ivh mdbtools-odbc-0.5-1.i386.rpm

4) Add the mdbtools driver to your unixODBC config.

Create a new text file. NON-LINUX user: Beware do not do this on windows as you might get werid new lines, use vi.

 

[MDBToolsODBC]

Description = MDB Tools ODBC drivers

Driver = /usr/lib/libmdbodbc.so.0

Setup =

FileUsage = 1

CPTimeout =

CPReuse =

NOTE: The driver may be in /usr/local/lib/libmdbodbc.so.0. This happens if you build from source and use the make install command. The RPM puts it in /usr/lib.

Now install the driver using the file you created. This is called a template file.

odbcinst -i -d -f template.file

 

5) Define the datasource name. This is done in the /etc/odbc.ini file. So pull up this file in vi or another text editor and add the following lines.

 

[Dogs]

Description = Microsoft Access Database of Dogs

Driver = MDBToolsODBC

Database = /var/data/my_dog_db.mdb

Servername = localhost

UserName =

Password =

port = 5432

That’s it you should now have an odbc connection available. I will demonstrate using php, this assumes that your php is compiled with UnixODBC support, the version that ships with Redhat 9 does if yours does not then you can learn how here.

 

So I will write a quick php script to query my dogs database and print out the names and weights of my dogs.

 

$myDB = odbc_connect("Dogs","","");

$query = "select name, weight from dog_list";

$result = odbc_exec($myDB, $query);

while (odbc_fetch_row($result)) {

print "Name = " . odbc_result($result,"name");

print "

Weight = " . odbc_result($result,"weight");

}

If you get a php error that says odbc_connect is not a function then see if you have php-odbc installed. Do rpm -qa php-odbc. If you see php-odbc returned then you have it if not install it., the rpm is available on the redhat discs.

 

Limitations:

- As of the time of writing this entry MDBTools did not support write access to the mdb files. This was fine for my purposes as I was reading data in and sticking it into a mysql database.

- There is a bug in MDBTools v0.5 which does not allow you to query tables or columns with an underscore. This was a bug I hit early on, but it has been fixed in new version 0.6 but that has not been released as of the time of writing this article. So I recompiled the 0.5 source code with the fix from the 0.6 CVS repository. I have bundled it into a 0.5 release and have the two rpms mentioned above here:

mdbtools-0.5-1.i386.rpm

mdbtools-odbc-0.5-1.i386.rpm

 

I would check the official download site before using my hacked version as I’m sure this bug will be fixed in 0.6 (plus rumor has write access will be present as well).