TimGoekeThomasLockhart1998-10-21ODBC Interface
Background information originally by Tim Goeke
(tgoeke@xpressway.com)
ODBC (Open Database Connectivity) is an abstract
API
that allows you to write applications that can interoperate
with various RDBMS servers.
ODBC provides a product-neutral interface
between frontend applications and database servers,
allowing a user or developer to write applications that are
transportable between servers from different manufacturers..
Background
The ODBC API matches up
on the backend to an ODBC-compatible data source.
This could be anything from a text file to an Oracle or
Postgres RDBMS.
The backend access come from ODBC drivers,
or vendor specifc drivers that
allow data access. psqlODBC is such a driver,
along with others that are
available, such as the OpenLink ODBC drivers.
Once you write an ODBC application,
you should be able to connect to any
back end database, regardless of the vendor, as long as the database schema
is the same.
For example. you could have MS SQL Server
and Postgres servers that have
exactly the same data. Using ODBC,
your Windows application would make exactly the
same calls and the back end data source would look the same (to the Windows
app).
Installation
The first thing to note about the psqlODBC> driver
(or any ODBC> driver) is that there must exist a
driver manager> on the system where the
ODBC> driver is to be used. There exists a free
ODBC> driver for Unix called iODBC>
which can be obtained via http://www.iodbc.org.
Instructions for installing iODBC> are contained in
the iODBC> distribution. Having said that, any
driver manager that you can find for your platform should support
the psqlODBC> driver, or any other ODBC>
driver for that matter.
To install psqlODBC> you simply need to supply the
The installation-wide configuration file odbcinst.ini> will be
installed into the directory /usr/local/pgsql/etc/>, or equivalent,
depending on what
Additionally, you should install the ODBC catalog extensions. That will
provide a number of functions mandated by the ODBC standard that are not
supplied by PostgreSQL> by default. The file
/usr/local/pgsql/share/odbc.sql> (in the default installation layout)
contains the appropriate definitions, which you can install as follows:
psql -d template1 -f LOCATION>/odbc.sql
where specifying template1 as the target
database will ensure that all subsequent new databases will
have these same definitions.
Supported PlatformspsqlODBC has been built and tested
on Linux. There have been reports of success
with FreeBSD and with Solaris. There are no known restrictions
on the basic code for other platforms which already support
Postgres.
Configuration Files~/.odbc.ini contains user-specified access information
for the psqlODBC driver.
The file uses conventions typical for Windows
Registry files, but despite this restriction can be made to work.
The .odbc.ini file has three required sections.
The first is [ODBC Data Sources]
which is a list of arbitrary names and descriptions for each database
you wish to access. The second required section is the
Data Source Specification and there will be one of these sections
for each database.
Each section must be labeled with the name given in
[ODBC Data Sources] and must contain the following entries:
Driver = prefix/lib/libpsqlodbc.so
Database=DatabaseName
Servername=localhost
Port=5432
Remember that the Postgres database name is
usually a single word, without path names of any sort.
The Postgres server manages the actual access
to the database, and you need only specify the name from the client.
Other entries may be inserted to control the format of the display.
The third required section is [ODBC]
which must contain the InstallDir keyword
and which may contain other options.
Here is an example .odbc.ini file,
showing access information for three databases:
[ODBC Data Sources]
DataEntry = Read/Write Database
QueryOnly = Read-only Database
Test = Debugging Database
Default = Postgres Stripped
[DataEntry]
ReadOnly = 0
Servername = localhost
Database = Sales
[QueryOnly]
ReadOnly = 1
Servername = localhost
Database = Sales
[Test]
Debug = 1
CommLog = 1
ReadOnly = 0
Servername = localhost
Username = tgl
Password = "no$way"
Port = 5432
Database = test
[Default]
Servername = localhost
Database = tgl
Driver = /opt/postgres/current/lib/libpsqlodbc.so
[ODBC]
InstallDir = /opt/applix/axdata/axshlib
Windows Applications
In the real world, differences in drivers and the level of
ODBC support
lessens the potential of ODBC:
Access, Delphi, and Visual Basic all support ODBC directly.
Under C++, such as Visual C++,
you can use the C++ ODBC API.
In Visual C++, you can use the CRecordSet class, which wraps the
ODBC API
set within an MFC 4.2 class. This is the easiest route if you are doing
Windows C++ development under Windows NT.
Writing Applications
If I write an application for Postgres
can I write it using ODBC calls
to the Postgres server,
or is that only when another database program
like MS SQL Server or Access needs to access the data?
The ODBC API
is the way to go.
For Visual C++ coding you can find out more at
Microsoft's web site or in your VC++ docs.
Visual Basic and the other RAD tools have Recordset objects
that use ODBC
directly to access data. Using the data-aware controls, you can quickly
link to the ODBC back end database
(very quickly).
Playing around with MS Access will help you sort this out. Try using
File->Get External Data.
You'll have to set up a DSN first.
ApplixWareApplixWare has an
ODBC database interface
supported on at least some platforms.
ApplixWare 4.4.2 has been
demonstrated under Linux with Postgres 7.0
using the psqlODBC
driver contained in the Postgres distribution.
ConfigurationApplixWare must be configured correctly
in order for it to
be able to access the Postgres
ODBC software drivers.
Enabling ApplixWare Database Access
These instructions are for the 4.4.2 release of
ApplixWare on Linux.
Refer to the Linux Sys Admin on-line book
for more detailed information.
You must modify axnet.cnf so that
elfodbc can
find libodbc.so
(the ODBC driver manager) shared library.
This library is included with the ApplixWare distribution,
but axnet.cnf needs to be modified to point to the
correct location.
As root, edit the file
applixroot/applix/axdata/axnet.cnf.
At the bottom of axnet.cnf,
find the line that starts with
#libFor elfodbc /ax/...
Change line to read
libFor elfodbc applixroot/applix/axdata/axshlib/lib
which will tell elfodbc to look in this directory
for the ODBC support library.
Typically Applix is installed in
/opt so the full path would be
/opt/applix/axdata/axshlib/lib,
but if you have installed Applix
somewhere else then change the path accordingly.
Create .odbc.ini as
described above. You may also want to add the flag
TextAsLongVarchar=0
to the database-specific portion of .odbc.ini
so that text fields will not be shown as **BLOB**.
Testing ApplixWare ODBC Connections
Bring up Applix Data
Select the Postgres database of interest.
Select Query->Choose Server.
Select ODBC, and click Browse.
The database you configured in .odbc.ini
should be shown. Make sure that the
Host: field
is empty (if it is not, axnet will try to contact axnet on another machine
to look for the database).
Select the database in the box that was launched by Browse,
then click OK.
Enter username and password in the login identification dialog,
and click OK.
You should see "Starting elfodbc server"
in the lower left corner of the
data window. If you get an error dialog box, see the debugging section
below.
The 'Ready' message will appear in the lower left corner of the data
window. This indicates that you can now enter queries.
Select a table from Query->Choose tables, and then select Query->Query
to access the database. The first 50 or so rows from the table should
appear.
Common Problems
The following messages can appear while trying to make an
ODBC connection through
Applix Data:
Cannot launch gateway on server
elfodbc can't find libodbc.so.
Check your axnet.cnf.
Error from ODBC Gateway:
IM003::[iODBC][Driver Manager]Specified driver could not be loaded
libodbc.so cannot find the driver listed in
.odbc.ini. Verify the settings.
Server: Broken Pipe
The driver process has terminated due to some other
problem. You might not have an up-to-date version
of the Postgres
ODBC package.
setuid to 256: failed to launch gateway
The September release of ApplixWare v4.4.1 (the first release with official
ODBC support under Linux) shows problems when usernames
exceed eight (8) characters in length.
Problem description ontributed by Steve Campbell
(scampbell@lear.com).
Author
Contributed by Steve Campbell (scampbell@lear.com),
1998-10-20
The axnet program's security system
seems a little suspect. axnet does things
on behalf of the user and on a true
multiple user system it really should be run with root security
(so it can read/write in each user's directory).
I would hesitate to recommend this, however, since we have no idea what
security holes this creates.
Debugging ApplixWare ODBC Connections
One good tool for debugging connection problems uses the Unix system
utility strace.
Debugging with strace
Start applixware.
Start an strace on
the axnet process. For example, if
% ps -aucx | grep ax
shows
cary 10432 0.0 2.6 1740 392 ? S Oct 9 0:00 axnet
cary 27883 0.9 31.0 12692 4596 ? S 10:24 0:04 axmain
Then run
% strace -f -s 1024 -p 10432
Check the strace output.
Note from Cary
Many of the error messages from ApplixWare
go to stderr,
but I'm not sure where stderr
is sent, so strace is the way to find out.
For example, after getting
a "Cannot launch gateway on server",
I ran strace on axnet and got
[pid 27947] open("/usr/lib/libodbc.so", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 27947] open("/lib/libodbc.so", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 27947] write(2, "/usr2/applix/axdata/elfodbc:
can't load library 'libodbc.so'\n", 61) = -1 EIO (I/O error)
So what is happening is that applix elfodbc is searching for libodbc.so, but it
can't find it. That is why axnet.cnf needed to be changed.
Running the ApplixWare Demo
In order to go through the
ApplixWare Data Tutorial, you need to create
the sample tables that the Tutorial refers to. The ELF Macro used to
create the tables tries to use a NULL condition
on many of the database columns,
and Postgres does not currently allow this option.
To get around this problem, you can do the following:
Modifying the ApplixWare Demo
Copy /opt/applix/axdata/eng/Demos/sqldemo.am
to a local directory.
Edit this local copy of sqldemo.am:
Search for 'null_clause = "NULL"
Change this to null_clause = ""
Start Applix Macro Editor.
Open the sqldemo.am file from the Macro Editor.
Select File->Compile and Save.
Exit Macro Editor.
Start Applix Data.
Select *->Run Macro
Enter the value "sqldemo", then click OK.
You should see the progress in the status line of the data window
(in the lower left corner).
You should now be able to access the demo tables.
Useful Macros
You can add information about your
database login and password to the standard Applix start-up
macro file. This is an example
~/axhome/macros/login.am file:
macro login
set_set_system_var@("sql_username@","tgl")
set_system_var@("sql_passwd@","no$way")
endmacro
You should be careful about the file protections on any file containing
username and password information.