DBI::FAQ (3)

Leading comments

Automatically generated by Pod::Man 2.28 (Pod::Simple 3.29)

Standard preamble:
========================================================================

(The comments found at the beginning of the groff file "man3/DBI::FAQ.3pm".)

NAME

DBI::FAQ -- The Frequently Asked Questions for the Perl5 Database Interface

SYNOPSIS

    perldoc DBI::FAQ

VERSION

This document is currently at version 0.38, as of February 8th, 2000.

That's very old. A newer

can be found at <faq.dbi-support.com>

Neither this document nor that web site are actively maintained. Volunteers are welcome.

DESCRIPTION

This document serves to answer the most frequently asked questions on both the Mailing Lists and personally to members of the 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 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

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 defined by 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

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

and are generally not supported.

Here's a list of DBperl modules, their corresponding

counterparts and support information. Please note, the author's listed here generally do not maintain the module for the same database. These email addresses are unverified and should only be used for queries concerning the perl4 modules listed below. driver queries should be directed to the dbi-users mailing list.

    Module Name Database Required   Author          DBI
    ----------- -----------------   ------          ---
    Sybperl     Sybase              Michael Peppler DBD::Sybase
                                    <mpeppler@itf.ch>
    Oraperl     Oracle 6 & 7        Kevin Stock     DBD::Oracle
                                    <dbi-users@perl.org>
    Ingperl     Ingres              Tim Bunce &     DBD::Ingres
                                    Ted Lemon
                                    <dbi-users@perl.org>
    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

modules have DBperl emulation layers, so, DBD::Oracle comes with an Oraperl emulation layer, which allows you to run legacy oraperl scripts without modification. The emulation layer translates the oraperl calls into calls and executes them through the switch.

Here's a table of emulation layer information:

    Module                  Emulation Layer     Status
    ------          ---------------     ------
    DBD::Oracle     Oraperl             Complete
    DBD::Informix   Isqlperl            Under development
    DBD::Ingres     Ingperl             Complete?
    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

Specification. It's use is being deprecated in favour of DBD::mSQL. Msqlperl may be downloaded from via:

    www.perl.com/cgi-bin/cpan_mod?module=Msqlperl

1.2. Where can I get it from?

The Comprehensive Perl Archive Network resources should be used for retrieving up-to-date versions of the and drivers. may be accessed via Tom Christiansen's splendid multiplexer program located at:

    www.perl.com/CPAN

For more specific version information and exact URLs of drivers, please see the

drivers list and the module pages which can be found on:

    dbi.perl.org

This list is automatically generated on a nightly basis from

and should be up-to-date.

1.3. Where can I get more information?

There are a few information sources on

Programming the Perl

DBI

``Programming the Perl

DBI''

is the official book on the

DBI

written by Alligator Descartes and Tim Bunce and published by O'Reilly & Associates. The book was released on February 9th, 2000.

The table of contents is:

    Preface
    1. Introduction
        From Mainframes to Workstations
        Perl
        DBI in the Real World
        A Historical Interlude and Standing Stones
    2. Basic Non-DBI Databases
        Storage Managers and Layers
        Query Languages and Data Functions
        Standing Stones and the Sample Database
        Flat-File Databases
        Putting Complex Data into Flat Files
        Concurrent Database Access and Locking
        DBM Files and the Berkeley Database Manager
        The MLDBM Module
        Summary
    3. SQL and Relational Databases
        The Relational Database Methodology
        Datatypes and NULL Values
        Querying Data
        Modifying Data Within Tables
        Creating and Destroying Tables
    4. Programming with the DBI
        DBI Architecture
        Handles
        Data Source Names
        Connection and Disconnection
        Error Handling
        Utility Methods and Functions
    5. Interacting with the Database
        Issuing Simple Queries
        Executing Non-SELECT Statements
        Binding Parameters to Statements
        Binding Output Columns
        do() Versus prepare()
        Atomic and Batch Fetching
    6. Advanced DBI
        Handle Attributes and Metadata
        Handling LONG/LOB Data
        Transactions, Locking, and Isolation
    7. ODBC and the DBI
        ODBC -- Embraced and Extended
        DBI -- Thrashed and Mutated
        The Nuts and Bolts of ODBC
        ODBC from Perl
        The Marriage of DBI and ODBC
        Questions and Choices
        Moving Between Win32::ODBC and the DBI
        And What About ADO?
    8. DBI Shell and Database Proxying
        dbish -- The DBI Shell
        Database Proxying
    A. DBI Specification
    B. Driver and Database Characteristics
    C. ASLaN Sacred Site Charter
    Index

The book should be available from all good bookshops and can be ordered online either <I>via</I> O'Reilly & Associates

    www.oreilly.com/catalog/perldbi

or Amazon

    www.amazon.com/exec/obidos/ASIN/1565926994/dbi

POD

documentation

POD

s 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 "perldoc" program included with Perl.

The

DBI

Specification

The

POD

for the

DBI

Specification can be read with the:

    perldoc DBI

command. The Specification also forms Appendix A of ``Programming the Perl

DBI''.

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.

Drivers

Users of the

DBD

modules may read about some of the private functions and quirks of that driver by typing:

    perldoc <driver>

For example, the DBD::mSQL driver is bundled with driver-specific documentation that can be accessed by typing

    perldoc DBD::mSQL

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. The

DBI::FAQ

module should be downloaded and installed for the more up-to-date version.

The version of

DBI::FAQ

shipped with the "DBI" module may be slightly out of date.

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. This is available via

CPAN

as the module called Tk::POD and is highly recommended.

Driver and Database Characteristics

The driver summaries that were produced for Appendix B of ``Programming the Perl

DBI''

are available online at:

    dbi.perl.org

in the driver information table. These summaries contain standardised information on each driver and database which should aid you in selecting a database to use. It will also inform you quickly of any issues within drivers or whether a driver is not fully compliant with the

DBI

Specification.

Rambles, Tidbits and Observations

    dbi.perl.org/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.

Articles

A list of articles discussing the

DBI

can be found on the

DBI WWW

page at:

    dbi.perl.org

These articles are of varying quality and age, from the original Perl Journal article written by Alligator and Tim, to more recent debacles published online from about.com.

README

files

The

README

files included with each driver occasionally contains some 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:

    dbi.perl.org

Mailing Lists

There are three mailing lists for

DBI:

    dbi-announce@perl.org     -- for announcements, very low traffic
    dbi-users@perl.org        -- general user support
    dbi-dev@perl.org          -- for driver developers (no user support)

For information on how to subscribe, set digest mode etc, and unsubscribe, send an email message (the content will be ignored) to:

    dbi-announce-help@perl.org
    dbi-users-help@perl.org
    dbi-dev-help@perl.org

Mailing List Archives

US

Mailing List Archives

    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

    www.rosat.mpe-garching.mpg.de/mailing-lists/PerlDB-Interest

As per the

US

archive above.

Compilation Problems

2.1. Compilation problems or It fails the test!

First off, consult the for that driver in case there is useful information about the problem. It may be a known problem for your given architecture and operating system or database. You can check the files for each driver in advance online at:

    dbi.perl.org

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:

*

What the problem was, and test cases, if possible.

*

What you needed to do to fix it. Please make sure you mention everything.

*

Platform information, database version, perl version, 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.

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:

*

ALL

the information asked for in the

README

file in the problematic module. And we mean

ALL

of it. We don't put lines like that in documentation for the good of our health, or to meet obscure

README

file standards of length.

*

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:

    www.perl.com/cgi-bin/cpan_mod?module=Devel::CoreStack

*

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.

Finally, please be aware that some authors, including Tim Bunce, specifically request that you do not mail them directly. Please respect their wishes and use the email addresses listed in the appropriate module "README" file.

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

?

In terms of architecture - not much: Both define programming interfaces. Both allow multiple drivers to be loaded to do the actual work.

In terms of ease of use - much: The

is a 'high level' interface that, like Perl itself, strives to make the simple things easy while still making the hard things possible. The is a 'low level' interface. All nuts-bolts-knobs-and-dials.

Now there's an

driver for the () the ``What's the difference'' question is more usefully rephrased as:

Chapter 7 of ``Programming the Perl

covers this topic in far more detail and should be consulted.

3.2 What's the difference between Win32::ODBC and

DBD::ODBC

?

The and thus has a different philosophy from the Win32::ODBC module:

The Win32::ODBC module is a 'thin' layer over the low-level

The defines a simpler 'higher level' interface.

The Win32::ODBC module gives you access to more of the

The and give you access to only the essentials. (But, unlike Win32::ODBC, the and do support parameter binding and multiple prepared statements which reduces the load on the database server and can dramatically increase performance.)

The Win32::ODBC module only works on Win32 systems. The

and are very portable and work on Win32 and Unix.

The

and modules are supplied as a standard part of the Perl 5.004 binary distribution for Win32 (they don't work with the older, non-standard, ActiveState port).

Scripts written with the

and are faster than Win32::ODBC on Win32 and are trivially portable to other supported database types.

The

offers optional automatic printing or die()ing on errors which makes applications simpler and more robust.

The current

driver version 0.16 is new and not yet fully stable. A new release is due soon [relative to the date of the next issue :-] and will be much improved and offer more functionality.

To summarise: The Win32::ODBC module is your best choice if you need access to more of the

than the gives you. Otherwise, the and combination may be your best bet.

Chapter 7 of ``Programming the Perl

covers this topic in far more detail and should be consulted.

3.3 Is

DBI

supported under Windows 95 /

NT

platforms?

Finally, yes! Jeff Urlwin has been working diligently on building and 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.

The

and DBD::Oracle Win32 ports are now a standard part of so, downloading of version higher than 0.81 should work fine as should using the most recent DBD::Oracle version.

3.4 Can I access Microsoft Access or SQL-Server databases with

DBI

?

Yes, use the driver.

3.5 Is there a

DBD

for <insert favourite database here>?

First check if a driver is available on by searching for the name of the database (including common abbreviations and aliases).

Here's a general query that'll match all distributions:

    search.cpan.org/search?query=DBD&mode=dist

If you can't find a driver that way, you could check if the database supports

drivers. If so then you could probably use the driver:

    search.cpan.org/dist/DBD-ODBC

If not, then try asking on the dbi-users mailing list.

3.6 What's

DBM

? And why should I use

DBI

instead?

Extracted from `` 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
        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,

is a perfectly satisfactory solution for essentially read-only databases, or small and simple datasets. However, for more scalable dataset handling, not to mention robust transactional locking, users are recommended to use a more powerful database engine via .

Chapter 2 of ``Programming the Perl

discusses files in detail.

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

site at:

    www.hughes.com.au

You may also wish to look at MySQL which is a more powerful database engine that has a similar feel to mSQL.

    www.tcx.se

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 Oracle

. Oracle's site is an excellent source of more information.

    www.oracle.com

Informix is another high-end

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 site at:

    www.informix.com

In the case of

fronted applications, mSQL may be a better option due to slow connection times between a script and the Oracle 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.

reflects a generic that will work for most databases, and has no database-specific functionality.

However, driver authors may, if they so desire, include hooks to database-specific functionality through the "func()" method defined in the

Script developers should note that use of functionality provided via the "func()" methods is very unlikely to be portable across databases.

Programming Questions

4.1 Is

DBI

any use for

CGI

programming?

In a word, yes! is hugely useful for programming! In fact, I would tentatively say that programming is one of two top uses for

confers the ability to programmers to power WWW-fronted databases to their users, which provides users with vast quantities of ordered data to play with. 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 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 service client requests.

Using the Apache mod_perl module by Doug MacEachern, the perl interpreter is embedded with the "httpd" children. The

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

site:

    www.apache.org

The mod_perl module can be downloaded from

via:

    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

via:

    www.perl.com/cgi-bin/cpan_mod?module=Apache::DBI

4.4 ``When I run a perl script from the command line, it works, but, when I run it under the httpd, it fails!'' 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.

One way to solve this problem is to set the environment for your database in a "BEGIN { }" block at the top of your script. Another technique is to configure your

server to pass-through certain environment variables to your scripts.

Similarly, you should check your "httpd" error logfile for any clues, as well as the ``Idiot's Guide To Solving Perl /

Problems'' and ``Perl Programming '' for further information. It is unlikely the problem is DBI-related.

The ``Idiot's Guide To Solving Perl /

Problems'' can be located at:

    www.perl.com/perl/faq/index.html

as can the ``Perl

Programming ''. Read these documents carefully!

4.5 How do I get the number of rows returned from a SELECT statement?

Count them. Read the docs for the "rows()" method.

Miscellaneous Questions

5.1 Can I do multi-threading with

DBI

?

Perl version 5.005 and later can be built to support multi-threading. The as of version 1.02, does not yet support multi-threading so it would be unsafe to let more than one thread enter the at the same time.

It is expected that some future version of the

will at least be thread-safe (but not thread-hot) by automatically blocking threads entering the while it's already in use.

5.2 How do I handle

BLOB

data with

DBI

?

Handling data with the is very straight-forward. columns are specified in a statement as per normal columns. However, you also need to specify a maximum size that the <I>database handle</I> can fetch using the "LongReadLen" attribute.

For example:

    ### $dbh is a connected database handle
    $sth = $dbh->prepare( "SELECT blob_column FROM blobby_table" );
    $sth->execute;

would fail.

    ### $dbh is a connected database handle
    ### Set the maximum BLOB size...
    $dbh->{LongReadLen} = 16384;        ### 16Kb...Not much of a BLOB!

    $sth = $dbh->prepare( "..." );

would succeed <I>provided no column values were larger than the specified value</I>.

If the

data is longer than the value of "LongReadLen", then an error will occur. However, the provides an additional piece of functionality that will automatically truncate the fetched to the size of "LongReadLen" if it is longer. This does not cause an error to occur, but may make your fetched data useless.

This behaviour is regulated by the "LongTruncOk" attribute which is set to a false value by default ( thus making overlong

fetches fail ).

    ### Set BLOB handling such that it's 16Kb and can be truncated
    $dbh->{LongReadLen} = 16384;
    $dbh->{LongTruncOk} = 1;

Truncation of

data may not be a big deal in cases where the contains run-length encoded data, but data containing checksums at the end, for example, a file, would be rendered useless.

5.3 How can I invoke stored procedures with

DBI

?

The does not define a database-independent way of calling stored procedures.

However, most database that support them also provide a way to call them from

statements - and the certainly supports that.

So, 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;" );   # Oracle-specific

You should also be able to "prepare" and "execute", which is the recommended way if you'll be calling the procedure often.

5.4 How can I get return values from stored procedures with

DBI

?

    Contributed by Jeff Urlwin

    $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;

Remember to perform error checking, though! ( Or use the "RaiseError" attribute ).

5.5 How can I create or drop a database with

DBI

?

Database creation and deletion are concepts that are entirely too abstract to be adequately supported by 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 in a worthwhile way.

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

?

See the "commit()" and "rollback()" methods in the Specification.

Chapter 6 of ``Programming the Perl

discusses transaction handling within the context of in more detail.

5.7 How are NULL values handled by

DBI

?

"NULL" values in are specified to be treated as the value "undef". "NULL"s can be inserted into databases as "NULL", for example:

    $rv = $dbh->do( "INSERT INTO table VALUES( NULL )" );

but when queried back, the "NULL"s 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 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.

5.9 Is

DBI

Year 2000 Compliant?

has no knowledge of understanding of what dates are. Therefore, itself does not have a Year 2000 problem. Individual drivers may use date handling code internally and therefore be potentially susceptible to the Year 2000 problem, but this is unlikely.

You may also wish to read the ``Does Perl have a Year 2000 problem?'' section of the Perl

at:

    www.perl.com/CPAN/doc/FAQs/FAQ/PerlFAQ.html

Support and Training

The Perl5 Database Interface is software. See the for more details.

However, some organizations are providing either technical support or training programs on

The present author has no knowledge as to the quality of these services. The links are included for reference purposes only and should not be regarded as recommendations in any way. Caveat emptor.

Commercial Support

The Perl Clinic

The Perl Clinic provides commercial support for Perl and Perl related problems, including the

DBI

and its drivers. Support is provided by the company with whom Tim Bunce, author of

DBI

and DBD::Oracle, works and ActiveState. For more information on their services, please see:

    www.perlclinic.com

Training

Westlake Solutions

A hands-on class for experienced Perl

CGI

developers that teaches how to write database-connected

CGI

scripts using Perl and

DBI

.pm. This course, along with four other courses on

CGI

scripting with Perl, is taught in Washington,

DC

; Arlington, Virginia; and on-site worldwide upon request.

See:

    www.westlake.com/training

for more details.

Other References

In this section, we present some miscellaneous links that may be of some interest to users. These are not verified and may result in unknown sites or missing documents.

    www-ccs.cs.umass.edu/db.html
    www.odmg.org/odmg93/updates_dbarry.html
    www.jcc.com/sql_stnd.html

AUTHOR

Alligator Descartes. Portions are Copyright their original stated authors.

COPYRIGHT

This document is Copyright (c)1994-2000 Alligator Descartes, with portions Copyright (c)1994-2000 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-2000 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

and 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.