PERL is an acronym for 'Practical Extraction and Report Language'. Perl is available on each and every operating system and hardware platform in the world. You can use Perl on Windows95/NT, Apple Macintosh iMac, all flavors of Unix (Solaris, HPUX, AIX, Linux, Irix, SCO etc..), mainframe MVS, desktop OS/2, OS/400, Amdahl UTS and many others. Perl runs EVEN on many unpopular or generally-unknown operating systems and hardware!! So do not be surprised if you see perl running on a very rarely used operating system. You can imagine the vast extent of the user base and developer base of Perl.
Perl interface for PostgreSQL is included in the distribution of PostgreSQL. Check in src/pgsql_perl5 directory.
The Perl Database Interface (DBI) is a database access Application Programming Interface (API) for the Perl Language. The Perl DBI API specification defines a set of functions, variables and conventions that provide a consistent database interface independent of the actual database being used.
Get DBD-Pg-0.89.tar.gz from below
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 independent 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 3GL layer. 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 list of DBperl modules, their corresponding DBI counterparts and support information. DBI driver queries should be directed to the dbi-users mailing list.
Module Name Database Required Author DBI
----------- ----------------- ------ ---
Sybperl Sybase Michael Peppler DBD::Sybase
<mpeppler@datamig.com>
http://www.mbay.net/~mpeppler
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
There are a few information sources on DBI.
The POD for the DBI Specification can be read with the command
$ perldoc DBI
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
Users of the DBD::mSQL module may read about some of the private
functions and quirks of that driver by typing:
$ perldoc DBD::mSQL
The Frequently Asked Questions is also available as
POD documentation. Read this by typing:
$ perldoc DBI::FAQ
POD in general - Information on writing POD, and on the philosophy of POD in
general, can be read by typing:
$ perldoc perlpod
See also -
The mailing lists that users may participate in are:
If you have a core dump, try the Devel::CoreStack module for generating a stack trace from the core dump. Devel::CoreStack can be found on CPAN at:
Email the dbi-users Mailing List stack trace, module versions, perl version, test cases, operating system versions and any other pertinent information. The more information you send, the quicker developers can track problems down.
The DBI and DBD::Oracle Win32 ports are now a standard part of DBI, so, downloading DBI of version higher than 0.81 should work fine. You can access Microsoft Access and SQL-Server databases from DBI via ODBC. Supplied with DBI-0.79 (and later) is an experimental DBI 'emulation layer' for the Win32::ODBC module. It's called DBI::W32ODBC. You will need the Win32::ODBC module.
In a word, yes! DBI is hugely useful for CGI programming! In fact, 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.
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:
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:
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 solve the problem. Similarly, you should check your httpd error logfile for any clues, as well as the ``Idiot's Guide To Solving Perl / CGI Problems'' and ``Perl CGI Programming FAQ'' for further information. It is unlikely the problem is DBI-related. Read BOTH these documents carefully!
For some OCI example code for Oracle that has multi-threaded SELECT statements, see:
Assuming that you have created a stored procedure within the target database, eg, an Oracle database, you can use $dbh->do to immediately execute the procedure. For example,
$dbh->do( "BEGIN someProcedure END" );
Remember to perform error checking, though!
$sth = $dbh->prepare( "BEGIN foo(:1, :2, :3); END;" );
$sth->bind_param(1, $a);
$sth->bind_param_inout(2, \$path, 2000);
$sth->bind_param_inout(3, \$success, 2000);
$sth->execute;
Database creation and deletion are concepts that are entirely 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. 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.
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 )" );
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' );
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, works. For more information on their services, please see :
See the section - Testing Perl PostgreSQL interface