![[ Home ]](/icons/headerbar_home.gif){kind=icon}
![[ Support ]](/icons/headerbar_support.gif){kind=icon}
![[ Documentation ]](/icons/headerbar_doc.gif){kind=icon}
![[ Systems ]](/icons/headerbar_systems.gif){kind=icon}
|
|
|
|
|
|
![[ Hermetica ]](/img/hermlogo.gif)
perldoc DBI::FAQ
``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.
Here's a diagram that demonstrates the principle:
![[ DBI Architecture ]](img/dbiarch.gif)
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 be directed to the dbi-users mailing list.
Perl4 Name Database Author DBI Driver
---------- -------- ------ ----------
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
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
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.
perldoc DBI
command.
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.
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.
perldoc DBD::mSQL
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.
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 workings of the interfaces.
http://www.tpj.com
Here is the putative table of contents for the book.
* Introduction
+ 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
http://www.hermetica.com/technologia/perl/DBI
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:
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.
http://www.rosat.mpe-garching.mpg.de/mailing-lists/PerlDB-Interest
As per the US archive above.
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:
perl -V), module version and DBI version.
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:
http://www.perl.com/cgi-bin/cpan_mod?module=Devel::CoreStack
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
Contributed by Tim Bunce and Jeff Urlwin
Supplied with DBI-0.79 ( and later ) is an experimental 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!
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.
``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
limitation on the usefulness of dbm systems.
However, dbm systems still provide a useful function for users with
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.
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.
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 detail. Information on Informix can be found on their WWW site at:
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.
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.
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.
Contributed by John D. Groenveld
The Apache httpd maintains a pool of httpd children to service client requests.
Using the Apache mod_perl module by Doug MacEachern, the 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=mod_perl
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
httpd!'' Why?
$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 Solving Perl / CGI Problems'' and ``Perl CGI Programming FAQ'' for
further information. It is unlikely the problem 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.
For some OCI example code for Oracle that has multi-threaded SELECT
statements, see:
http://www.hermetica.com/technologia/oracle/oci/orathreads.tar.gz
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
Note: This is Oracle specific. Contributed by Jeff Urlwin
$sth = $dbh->prepare( "BEGIN foo(:1, :2, :3); END;" ) # Oracle specific
|| 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.
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.
commit or rollback a statement with DBI?
commit or rollback methods in the DBI docs.
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.
func() methods all about?
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' );
Software developers should note that the func() methods are non-portable between databases.
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.
http://www.perl.co.uk/tpc
for more details.
http://www-ccs.cs.umass.edu/db.html
http://www.odmg.org/odmg93/updates_dbarry.html
http://www.jcc.com/sql_stnd.html
This document is Copyright (c)1997 Alligator Descartes. All rights reserved. Permission to distribute this document, in full or in part, via email, Usenet, ftp 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>.