DBI::FAQ -- The Frequently Asked Questions for the Perl5
Database Interface
SYNOPSIS
perldoc DBI::FAQ
VERSION
This document is currently at version 0.35, as of June
20th, 1997.
DESCRIPTION
This document serves to answer the most frequently asked
questions on both the DBI Mailing Lists and personally to
members of the DBI development team.
Basic Information & Information Sources
1.1 What is DBI, DBperl, Oraperl and *perl?
To quote Tim Bunce, the architect and author of DBI:
``DBI is a database access Application Programming Interface (API)
for the Perl Language. The DBI API Specification defines a set
of functions, variables and conventions that provide a consistent
database interface independant of the actual database being used.''
In simple language, the DBI interface allows users to
access multiple database types transparently. So, if you
connecting to an Oracle, Informix, mSQL, Sybase or
whatever database, you don't need to know the underlying
mechanics of the interface. The API defined by DBI will
work on all these database types.
A similar benefit is gained by the ability to connect to
two different databases of different vendor within the one
perl script, ie, I want to read data from an Oracle
database and insert it back into an Informix database all
within one program. The DBI layer allows you to do this
simply and powerfully.
DBperl is the old name for the interface specification.
It's usually now used to denote perl4 modules on database
interfacing, such as, oraperl, isqlperl, ingperl and so
on. These interfaces didn't have a standard API and are
generally not supported.
Here's a list of old DBperl's, their corresponding DBI
counterparts and support information. Please note, the
author's listed here generally do not maintain the DBI
module for the same database. These email addresses are
unverified and should only be used for queries concerning
the perl4 modules listed below. DBI driver queries should
---------- -------- ------ ----------
Sybperl Sybase Michael Peppler DBD::Sybase
<mpeppler@itf.ch>
Oraperl Oracle 6 & 7 Kevin Stock DBD::Oracle
<dbi-users@fugue.com>
Ingperl Ingres Tim Bunce & DBD::Ingres
Ted Lemon
<dbi-users@fugue.com>
Interperl Interbase Buzz Moschetti DBD::Interbase
<buzz@bear.com>
Uniperl Unify 5.0 Rick Wargo None
<rickers@coe.drexel.edu>
Pgperl Postgres Igor Metz DBD::Pg
<metz@iam.unibe.ch>
Btreeperl NDBM John Conover SDBM?
<john@johncon.com>
Ctreeperl C-Tree John Conover None
<john@johncon.com>
Cisamperl Informix C-ISAM Mathias Koerber None
<mathias@unicorn.swi.com.sg>
Duaperl X.500 Directory Eric Douglas None
User Agent
However, some DBI modules have DBperl emulation layers,
so, DBD::Oracle for example comes with an Oraperl
emulation layer, which allows you to run legacy oraperl
scripts without modification. The emulation layer
translates the oraperl API calls into the corresponding
DBI calls.
Here's a table of emulation layer information:
Module Emulation Layer Status
------ --------------- ------
DBD::Oracle Oraperl Complete
DBD::Ingres Ingperl Complete
DBD::Informix Isqlperl Under development
DBD::Sybase Sybperl Working? ( Needs verification )
DBD::mSQL Msqlperl Experimentally released with
DBD::mSQL-0.61
The Msqlperl emulation is a special case. Msqlperl is a
perl5 driver for mSQL databases, but does not conform to
the DBI Specification. It's use is being deprecated in
favour of DBD::mSQL. Msqlperl may be downloaded from CPAN
via:
http://www.perl.com/cgi-bin/cpan_mod?module=Msqlperl
DBI is primarily distributed from:
ftp://ftp.demon.co.uk/pub/perl/db
The Comprehensive Perl Archive Network resources should be
used for retrieving up-to-date versions of the drivers.
Local CPAN sites may be accessed via Tom Christiansen's
splendid CPAN multiplexer program located at:
http://www.perl.com/CPAN/
For more specific version information and exact URLs of
drivers, please see the DBI drivers list and the DBI
module pages which can be found on:
http://www.hermetica.com/technologia/perl/DBI
1.3. Where can I get more information?
There are a few information sources on DBI.
DBI Specification
http://www.hermetica.com/technologia/perl/DBI/doc/dbispec
There are two specifications available at this link,
the new DBI Draft Specification which is a rapidly
evolving document as Tim Bunce and the development
team drive towards a stable interface, and the old
historical DBperl Specification out of which the
current DBI interface evolved.
The latter document should be regarded as being of
historical interest only and should not serve as a
programming manual, or authoratative in any sense.
However, it is still a very useful reference source.
POD documentation
PODs are chunks of documentation usually embedded
within perl programs that document the code ``in
place'', providing a useful resource for programmers
and users of modules. POD for DBI and drivers is
beginning to become more commonplace, and
documentation for these modules can be read with the
following commands.
The DBI Specification
The POD for the DBI Specification can be read with
the:
Frequently Asked Questions
This document, the Frequently Asked Questions is
also available as POD documentation! You can read
this on your own system by typing:
perldoc DBI::FAQ
This may be more convenient to persons not
permanently, or conveniently, connected to the
Internet but the document may not be the latest
version.
Oraperl Users of the Oraperl emulation layer bundled with
DBD::Oracle, may read up on how to program with
the Oraperl interface by typing:
perldoc Oraperl
This will produce an updated copy of the original
oraperl man page written by Kevin Stock for perl4.
The oraperl API is fully listed and described
there.
DBD::mSQL
Users of the DBD::mSQL module may read about some
of the private functions and quirks of that driver
by typing:
perldoc DBD::mSQL
POD in general
Information on writing POD, and on the philosophy
of POD in general, can be read by typing:
perldoc perlpod
Users with the Tk module installed may be
interested to learn there is a Tk-based POD reader
available called tkpod, which formats POD in a
convenient and readable way.
Rambles, Tidbits and Observations
http://www.hermetica.com/technologia/perl/DBI/tidbits
There are a series of occasional rambles from various
people on the DBI mailing lists who, in an attempt to
clear up a simple point, end up drafting fairly
comprehensive documents. These are quite often varying
in quality, but do provide some insights into the
This is an article written by Alligator Descartes and
Tim Bunce on the structure of DBI. It was published in
issue 5 of ``The Perl Journal''. It's extremely good.
Go buy the magazine. In fact, buy all of them! ``The
Perl Journal''s WWW site is:
http://www.tpj.com
``DBperl''
This article, published in the November 1996 edition
of ``Dr. Dobbs Journal'' concerned DBperl. The author
of this edition apparently did not bother to contact
any of the DBI development team members for
verification of the information contained within his
article. Several reviews of the article on the dbi-
users mailing list were disparaging, to say the least.
The fact the article was written about DBperl instead
of DBI hints at the staleness of the information.
However, we include the reference for completeness'
sake.
``The Perl5 Database Interface''
This item is a book to be written by Alligator
Descartes ( for it is me ) and published by O'Reilly
and Associates this coming Winter.
Here is the putative table of contents for the book.
+ Databases
+ CGI / WWW
+ perl
* Basic Database Concepts
+ Types of Database
o Flat File
o AnyDBM
o RDBMS
+ Using Which Database For What...
* SQL
+ Why SQL?
+ Structuring Information In Databases
+ Retrieving Data From Databases
+ Manipulating Data and Data Structures
* DBI Architecture
* Programming with DBI
+ DBI Initialization
+ Handles
o Driver Handles
o Database Handles
o Statement Handles
+ Connection and Disconnection
+ Handling Errors
+ Issuing Simple Queries
+ Executing Atomic Statements
+ Statement MetaData
+ More perl-ish Statements
+ Binding
+ Transaction Handling
+ Utility Methods
+ Handle Attributes and Dynamic Variables
* DBI and ODBC
* The Database Drivers
+ DBD::Oracle and oraperl
+ DBD::Informix and isqlperl
+ DBD::mSQL and Msqlperl
* Case Studies
+ DBI and the WWW
+ Data Migration and Warehousing
+ Administration Software
* Appendix: API Reference / Specification
* Appendix: Resources
README files
The README files included with each driver
occasionally contains some very useful information (
no, really! ) that may be pertinent to the user.
Please read them. It makes our worthless existences
more bearable. These can all be read from the main DBI
WWW page at:
There are three mailing lists for DBI run by Ted
Lemon. These can all be subscribed to and unsubscribed
from via the World Wide Web at the URL of:
http://www.fugue.com/dbi
If you cannot successfully use the WWW form on the
above page, please subscribe to the list in the
following manner:
Email: 'dbi-XXX-request@fugue.com' with a message body of
'subscribe'
Where 'dbi-XXX' is the name of the mailing list you
are interested in. But note that your request will be
handled by a human and may take some time.
The lists that users may participate in are:
dbi-announce
This mailing list is for announcements only. Very
low traffic. The announcements are usually posted
on the main DBI WWW page.
dbi-dev This mailing list is intended for the use of
developers discussing ideas and concepts for the
DBI interface, API and driver mechanics. Only any
use for developers, or interested parties. Low
traffic.
dbi-users
This mailing list is a general discussion list
used for bug reporting, problem discussion and
general enquiries. Medium traffic.
Mailing List Archives
US Mailing List Archives
http://outside.organic.com/mail-archives/dbi-users/
Searchable hypermail archives of the three mailing
lists, and some of the much older traffic have
been set up for users to browse.
European Mailing List Archives
http://www.rosat.mpe-garching.mpg.de/mailing-lists/PerlDB-Interest
As per the US archive above.
Compilation Problems
First off, consult the online information about the
module, beit DBI itself, or a DBD, and see if it's a known
compilation problem on your architecture. These documents
can be found at:
http://www.hermetica.com/technologia/perl/DBI
If it's a known problem, you'll probably have to wait till
it gets fixed. If you're really needing it fixed, try the
following:
Attempt to fix it yourself
This technique is generally not recommended to the
faint-hearted. If you do think you have managed to
fix it, then, send a patch file ( context diff ) to
the author with an explanation of:
o What the problem was, and test cases, if possible.
o What you needed to do to fix it. Please make sure
you mention everything.
o Platform information, database version, perl
version (perl -V), module version and DBI version.
Email the author Do NOT whinge!
Please email the address listed in the WWW pages for
whichever driver you are having problems with. Do not
directly email the author at a known address unless it
corresponds with the one listed. Some authors,
including Tim Bunce, specifically do not want mail
sent directly to them.
We tend to have real jobs to do, and we do read the
mailing lists for problems. Besides, we may not have
access to <insert your favourite brain-damaged
platform here> and couldn't be of any assistance
anyway! Apologies for sounding harsh, but that's the
way of it!
However, you might catch one of these creative genii
at 3am when we're doing this sort of stuff anyway, and
get a patch within 5 minutes. The atmosphere in the
DBI circle is that we do appreciate the users'
problems, since we work in similar environments.
If you are planning to email the author, please
furnish as much information as possible, ie:
o ALL the information asked for in the README file
for the problematic module. And we mean ALL of it.
file standards of length.
o If you have a core dump, try the Devel::CoreStack
module for generating a stack trace from the core
dump. Send us that too. Devel::CoreStack can be
found on CPAN at:
http://www.perl.com/cgi-bin/cpan_mod?module=Devel::CoreStack
o Module versions, perl version, test cases,
operating system versions and any other pertinent
information.
Remember, the more information you send us, the
quicker we can track problems down. If you send us
no useful information, expect nothing back.
Email the dbi-users Mailing List
It's usually a fairly intelligent idea to cc the
mailing list anyway with problems. The authors all
read the lists, so you lose nothing by mailing there.
Platform and Driver Issues
3.1 What's the difference between ODBC and DBI?
Good question! To be filled in more detail! Meanwhile see
the notes at the end of the DBI README file.
3.2 Is DBI supported under Windows 95 / NT platforms?
Finally, yes! Jeff Urlwin has been working diligently on
building DBI and DBD::Oracle under these platforms, and,
with the advent of a stabler perl and a port of MakeMaker,
the project has come on by great leaps and bounds.
Recent DBI and DBD::Oracle modules will build and work
out-of-the-box on Win32 with the standard perl 5.004 (or
later) version of perl.
If you have to use the old non-standard ActiveWare perl
port you can't use the standard DBI and DBD::Oracle
modules out-of-the-box. Details of the changes required
and pre-patched versions can be found at:
http://www.hermetica.com/technologia/perl/DBI/win32
3.3 Can I access Microsoft Access or SQL-Server databases
with DBI?
DBI 'emulation layer' for the Win32::ODBC module. It's
called DBI::W32ODBC and is, at the moment, very minimal.
You will need the Win32::ODBC module available from:
http://www.roth.net
Given its status, problem reports without fixes are likely
to be ignored. You will also need the Win32 DBI patch kit
as supplied by Jeff Urlwin, which you can locate by
reading the previous question's answer.
To get back to the question, theoretically, yes, you can
access Microsoft Access and SQL-Server databases from DBI
via ODBC!
3.4 Is the a DBD for <insert favourite database here>?
Is is listed on the DBI drivers page?
http://www.hermetica.com/technologia/perl/DBI/DBD
If not, no. A complete absence of a given database driver
from that page means that no-one has announced any
intention to work on it.
A corollary of the above statement implies that if you see
an announcement for a driver not on the above page,
there's a good chance it's not actually a DBI driver, and
may not conform to the specifications. Therefore,
questions concerning problems with that code should not
really be addressed to the DBI Mailing Lists.
3.5 What's DBM? And why should I use DBI instead?
Extracted from ``DBI - The Database Interface for Perl
5'':
``UNIX was originally blessed with simple file-based ``databases'', namely
the dbm system. dbm lets you store data in files, and retrieve
that data quickly. However, it also has serious drawbacks.
File Locking
The dbm systems did not allow particularly robust file locking
capabilities, nor any capability for correcting problems arising through
simultaneous writes [ to the database ].
Arbitrary Data Structures
The dbm systems only allows a single fixed data structure:
key-value pairs. That value could be a complex object, such as a
[ C ] struct, but the key had to be unique. This was a large
simple datasets and limited resources, since they are fast, robust and
extremely well-tested. Perl modules to access dbm systems have now
been integrated into the core Perl distribution via the
AnyDBM_File module.''
To sum up, DBM is a perfectly satisfactory solution for
essentially read-only databases, or small and simple
datasets with a single user. However, for more powerful
and scaleable datasets, not to mention robust
transactional locking, users are recommended to use DBI.
3.6 When will mSQL-2 be supported?
As of DBD::mSQL-0.61, there has been support for mSQL-2.
However, there is no real support for any of the new
methods added to the core mSQL library regarding index
support yet. These are forthcoming and will be accessible
via func() methods private to DBD::mSQL. You can read
more about these private methods in the DBD::mSQL POD that
can be found by typing:
perldoc DBD::mSQL
provided you have DBD::mSQL correctly installed.
3.7 What database do you recommend me using?
This is a particularly thorny area in which an objective
answer is difficult to come by, since each dataset,
proposed usage and system configuration differs from
person to person.
From the current author's point of view, if the dataset is
relatively small, being tables of less than 1 million
rows, and less than 1000 tables in a given database, then
mSQL is a perfectly acceptable solution to your problem.
This database is extremely cheap, is wonderfully robust
and has excellent support. More information is available
on the Hughes Technology WWW site at:
http://www.hughes.com.au
If the dataset is larger than 1 million row tables or 1000
tables, or if you have either more money, or larger
machines, I would recommend the Oracle RDBMS. Oracle's
WWW site is an excellent source of more information.
http://www.oracle.com
Informix is another high-end RDBMS that is worth
considering. There are several differences between Oracle
and Informix which are too complex for this document to
http://www.informix.com
In the case of WWW fronted applications, mSQL may be a
better option due to slow connection times between a CGI
script and the Oracle RDBMS and also the amount of
resource each Oracle connection will consume. mSQL is
lighter resource-wise and faster.
These views are not necessarily representative of anyone
else's opinions, and do not reflect any corporate
sponsorship or views. They are provided as-is.
3.8 Is <insert feature here> supported in DBI?
Given that we're making the assumption that the feature
you have requested is a non-standard database-specific
feature, then the answer will be no.
DBI reflects a generic API that will work for most
databases, and has no database-specific functionality
defined.
However, driver authors may, if they so desire, include
hooks to database-specific functionality through the
func() method defined in the DBI API. Script developers
should note that use of functionality provided via the
func() methods is unlikely to be portable across
databases.
Programming Questions
4.1 Is DBI any use for CGI programming?
In a word, yes! DBI is hugely useful for CGI programming!
In fact, I would tentatively say that CGI programming is
one of two top uses for DBI.
DBI confers the ability to CGI programmers to power
WWW-fronted databases to their users, which provides users
with vast quantities of ordered data to play with. DBI
also provides the possibility that, if a site is receiving
far too much traffic than their database server can cope
with, they can upgrade the database server behind the
scenes with no alterations to the CGI scripts.
4.2 How do I get faster connection times with DBD::Oracle
and CGI?
Contributed by John D. Groenveld
The Apache httpd maintains a pool of httpd children to
perl interpreter is embedded with the httpd children. The
CGI, DBI, and your other favorite modules can be loaded at
the startup of each child. These modules will not be
reloaded unless changed on disk.
For more information on Apache, see the Apache Project's
WWW site:
http://www.apache.org/
The mod_perl module can be downloaded from CPAN via:
http://www.perl.com/cgi-bin/cpan_mod?module=Apache
4.3 How do I get persistent connections with DBI and CGI?
Contributed by John D. Groenveld
Using Edmund Mergl's Apache::DBI module, database logins
are stored in a hash with each of these httpd child. If
your application is based on a single database user, this
connection can be started with each child. Currently,
database connections cannot be shared between httpd
children.
Apache::DBI can be downloaded from CPAN via:
http://www.perl.com/cgi-bin/cpan_mod?module=Apache::DBI
4.4 ``My perl script runs from the command line, but fails
under the httpd!'' Why?
Basically, a good chance this is occurring is due to the
fact that the user that you ran it from the command line
as has a correctly configured set of environment
variables, in the case of DBD::Oracle, variables like
$ORACLE_HOME, $ORACLE_SID or TWO_TASK.
The httpd process usually runs under the user id of
nobody, which implies there is no configured environment.
Any scripts attempting to execute in this situation will
correctly fail.
To solve this problem, set the environment for your
database in a BEGIN { } block at the top of your script.
This will generally solve the problem.
Similarly, you should check your httpd error logfile for
any clues, as well as the very valuable ``Idiot's Guide To
is DBI-related.
The ``Idiot's Guide To Solving Perl / CGI Problems'' can
be located at:
http://www.perl.com/perl/faq/index.html
as can the ``Perl CGI Programming FAQ''. Read BOTH these
documents carefully! They will probably save you many
hours of work.
5.1 Can I do multi-threading with DBI?
As of the current date of this FAQ ( see top of page ),
no. perl does not support multi-threading. However, multi-
threading is expected to become part of the perl core
distribution as of version 5.005, which implies that DBI
may support multi-threading fairly soon afterwards.
For some OCI example code for Oracle that has multi-
threaded SELECT statements, see:
http://www.hermetica.com/technologia/oracle/oci/orathreads.tar.gz
5.2 How do I handle BLOB data with DBI?
To be written.
5.3 How can I invoke stored procedures with DBI?
There is currently no standard way to call stored
procedures with DBI. However, if the database lets you
use SQL to call stored procedures then the DBI and DBD
driver probably will to.
For example, assuming that you have created a stored
procedure within an Oracle database, you can use
$dbh->do() to immediately execute the procedure:
$dbh->do( "BEGIN someProcedure END;" ); # Oracle specific
5.4 How can I get return values from stored procedures
with DBI?
Note: This is Oracle specific. Contributed by Jeff Urlwin
|| die $sth->errstr;
$sth->bind_param(1, $a) || die $sth->errstr;
$sth->bind_param_inout(2, \$path, 2000) || die $sth->errstr;
$sth->bind_param_inout(3, \$success, 2000) || die $sth->errstr;
$sth->execute || die $sth->errstr;
Note the error checking, it may seem like extra work but
it'll probably save you hours in the long run. See
$sth->{RaiseError} and $sth->{printError} in the DBI docs
for easier ways to get the same effect.
5.5 How can I create or drop a database with DBI?
Database creation and deletion are concepts that are too
abstract to be adequately supported by DBI. For example,
Oracle does not support the concept of dropping a database
at all! Also, in Oracle, the database server essentially
is the database, whereas in mSQL, the server process runs
happily without any databases created in it. The problem
is too disparate to attack easily.
Some drivers, therefore, support database creation and
deletion through the private func() methods. You should
check the documentation for the drivers you are using to
see if they support this mechanism.
5.6 How can I commit or rollback a statement with DBI?
To be written. See the commit or rollback methods in the
DBI docs.
5.7 How are NULL values handled by DBI?
NULL values in DBI are specified to be treated as the
value undef. NULLs can be inserted into databases as
NULL, for example:
$rv = $dbh->do( "INSERT INTO table VALUES( NULL )" );
but when queried back, the NULLs should be tested against
undef. This is standard across all drivers.
5.8 What are these func() methods all about?
The func() method is defined within DBI as being an entry
point for database-specific functionality, eg, the ability
to create or drop databases. Invoking these driver-
specific methods is simple, for example, to invoke a
createDatabase method that has one argument, we would
write:
$rv = $dbh->func( 'argument', 'createDatabase' );
are non-portable between databases.
Support and Training
The Perl5 Database Interface is FREE software. IT COMES
WITHOUT WARRANTY OF ANY KIND. See the DBI README and DBI
documentation for more details.
However, some organizations are providing either technical
support or training programs on DBI. The present author
has no knowledge as to the quality of these services. The
links are included for reference purposes only.
Commercial Support
The Perl Clinic
The Perl Clinic can arrange commercial support
contracts for Perl, DBI, DBD::Oracle and Oraperl.
Support is provided by the company with whom Tim
Bunce, author of DBI and DBD::Oracle, works. For more
information on their services, please see:
http://www.perl.co.uk/tpc
for more details.
Training
No training programs are known at this time.
Other References
In this section, we present some miscellaneous WWW links
that may be of some interest to DBI users. These are not
verified and may result in unknown sites or missing
documents.
http://www-ccs.cs.umass.edu/db.html
http://www.odmg.org/odmg93/updates_dbarry.html
http://www.jcc.com/sql_stnd.html
AUTHOR
Alligator Descartes <descarte@hermetica.com>
COPYRIGHT
This document is Copyright (c)1994-1997 Alligator
Descartes, with portions Copyright (c)1994-1997 their
original authors. This module is released under the
'Artistic' license which you can find in the perl
distribution.
This document is Copyright (c)1997 Alligator Descartes.
archives or http is granted providing that no charges are
involved, reasonable attempt is made to use the most
current version and all credits and copyright notices are
retained ( the AUTHOR and COPYRIGHT sections ). Requests
for other distribution rights, including incorporation
into commercial products, such as books, magazine articles
or CD-ROMs should be made to Alligator Descartes
<descarte@hermetica.com>.