Unix/Linux Go Back    

RedHat 9 (Linux i386) - man page for dbi::dbd (redhat section 3)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

DBI::DBD(3)		       User Contributed Perl Documentation		      DBI::DBD(3)

       DBI::DBD - DBD Driver Writer's Guide

	 perldoc DBI::DBD

	 $Revision: 11.11 $
	 $Date: 2002/11/30 00:46:18 $

       This document is still a minimal draft which is in need of further work.

       The changes will occur both because the DBI specification is changing and hence the
       requirements on DBD drivers change, and because feedback from people reading this document
       will suggest improvements to it.

       Please read the DBI documentation first and fully, including the DBI FAQ.  The reread the
       DBI specification again as you're reading this. It'll help.

       This document is a patchwork of contributions from various authors.  More contributions
       (preferably as patches) are very welcome.

       This document is primarily intended to help people writing new database drivers for the
       Perl Database Interface (Perl DBI).  It may also help others interested in discovering why
       the internals of a DBD driver are written the way they are.

       This is a guide.  Few (if any) of the statements in it are completely authoritative under
       all possible circumstances.  This means you will need to use judgement in applying the
       guidelines in this document.  If in any doubt at all, please do contact the dbi-dev mail-
       ing list (details given below) where Tim Bunce and other driver authors can help.

       The primary web-site for locating DBI software and information is


       There are 2 main and one auxilliary mailing lists for people working with DBI.  The pri-
       mary lists are dbi-users@perl.org for general users of DBI and DBD drivers, and
       dbi-dev@perl.org mainly for DBD driver writers (don't join the dbi-dev list unless you
       have a good reason).  The auxilliary list is dbi-announce@perl.org for announcing new
       releases of DBI or DBD drivers.

       You can join these lists by accessing the web-site <http://dbi.perl.org/>.  The lists are
       closed so you cannot send email to any of the lists unless you join the list first.

       You should also consider monitoring the comp.lang.perl.* newsgroups, especially

       The definitive book on Perl DBI is 'Programming the Perl DBI: Database programming with
       Perl' by Alligator Descartes and Tim Bunce, published by O'Reilly Associates, February
       2000, ISBN 1-56592-699-4.  Buy it now if you have not already done so.

       Before writing a new driver, it is in your interests to find out whether there already is
       a driver for your database.  If there is such a driver, it would be much easier to make
       use of it than to write your own!

       Locating drivers

       The primary web-site for locating Perl software is <http://search.cpan.org/>.  You should
       look under the various modules listings for the software you are after. For example:


       Follow the DBD:: and DBIx:: links at the top to see those subsets.

       See the DBI docs for information on DBI web sites and mailing lists.

       Registering a new driver

       Before going through any official registration process, you will need to establish that
       there is no driver already in the works.  You'll do that by asking the DBI mailing lists
       whether there is such a driver available, or whether anybody is working on one.

       Writing a pure Perl driver is surprisingly simple. However, there are some problems one
       should be aware of. The best option is of course picking up an existing driver and care-
       fully modifying one method after the other.

       Also look carefully at DBD::AnyData and DBD::Template.

       As an example we take a look at the DBD::File driver, a driver for accessing plain files
       as tables, which is part of the DBD::CSV package. In what follows I assume the name
       "Driver" for your new package: The least thing we have to implement are the files "Make-
       file.PL" and "Driver.pm".


       You typically start with writing "Makefile.PL", a Makefile generator.  The contents of
       this file are described in detail in the MakeMaker man pages, it's definitely a good idea
       if you start reading them.  At least you should know about the variables CONFIGURE,
       SION_FROM, clean, depend, realclean from the "ExtUtils::MakeMaker" man page: These are
       used in almost any Makefile.PL. Additionally read the section on Overriding MakeMaker
       Methods and the descriptions of the distcheck, disttest and dist targets: They will defi-
       nitely be useful for you.

       Of special importance for DBI drivers is the postamble method from the "ExtUtils::MM_Unix"
       man page. And for Emacs users I recommend the libscan method.

       Now an example, I use the word "Driver" wherever you should insert your driver's name:

	 # -*- perl -*-

	 use DBI 1.03;
	 use DBI::DBD;
	 use ExtUtils::MakeMaker;

	     dbd_edit_mm_attribs( {
		 'NAME' 	=> 'DBD::Driver',
		 'VERSION_FROM' => 'Driver.pm',
		 'INC'		=> $DBI_INC_DIR,
		 'dist' 	=> { 'SUFFIX'	=> '.gz',
				       'COMPRESS' => 'gzip -9f' },
		 'realclean'	=> { FILES => '*.xsi' },
	     } )

	 package MY;
	 sub postamble { return main::dbd_postamble(@_); }
	 sub libscan {
	     my ($self, $path) = @_;
	     ($path =~ m/\~$/) ? undef : $path;

       Note the calls to dbd_edit_mm_attribs() and dbd_postamble().

       See also ExtUtils::MakeMaker(3). ExtUtils::MM_Unix(3).

       README file

       The README file should describe what the driver is for, the pre-requisites for the build
       process, the actual build process, and how to report errors. Users will find ways of
       breaking the driver build and test process which you would never even dreamed to be possi-
       ble in your nightmares.	Therefore, you need to write this document defensively and pre-
       cisely.	Also, it is in your interests to ensure that your tests work as widely as possi-
       ble. As always, use the README from one of the established drivers as a basis for your


       The MANIFEST will be used by the Makefile's dist target to build the distribution tar file
       that is uploaded to CPAN. It should list every file that you want to include in your dis-
       tribution, one per line.


       The CPAN module provides an extremely powerful bundle mechanism that allows you to specify
       pre-requisites for your driver.	The primary pre-requisite is Bundle::DBI; you may want or
       need to add some more.  With the bundle set up correctly, the user can type:

	       perl -MCPAN -e 'install Bundle::DBD::Driver'

       and Perl will download, compile, test and install all the Perl modules needed to build
       your driver.

       A suitable skeleton for this file is shown below.  The prerequisite modules are listed in
       the CONTENTS section, with the official name of the module followed by a dash and an
       informal name or description.  Listing Bundle::DBI as the main pre-requisite simplifies
       life.  Don't forget to list your driver.  Note that unless the DBMS is itself a Perl mod-
       ule, you cannot list it as a pre-requisite in this file.  You are strongly advised to keep
       the version of the bundle in sync with the version of your driver.  You might want to add
       configuration management, copyright, and licencing information at the top.

	 package Bundle::DBD::Driver;

	 $VERSION = '0.01';



	 =head1 NAME

	 Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules

	 =head1 SYNOPSIS

	 C<perl -MCPAN -e 'install Bundle::DBD::Driver'>

	 =head1 CONTENTS

	 Bundle::DBI  - Bundle for DBI by TIMB (Tim Bunce)

	 DBD::Driver  - DBD::Driver by YOU (Your Name)


	 This bundle includes all the modules used by the Perl Database
	 Interface (DBI) driver for Driver (DBD::Driver), assuming the
	 use of DBI version 1.13 or later, created by Tim Bunce.

	 If you've not previously used the CPAN module to install any
	 bundles, you will be interrogated during its setup phase.
	 But when you've done it once, it remembers what you told it.
	 You could start by running:

	   C<perl -MCPAN -e 'install Bundle::CPAN'>

	 =head1 SEE ALSO


	 =head1 AUTHOR

	 Your Name E<lt>F<you@yourdomain.com>E<gt>

	 =head1 THANKS

	 This bundle was created by ripping off Bundle::libnet created by
	 Graham Barr E<lt>F<gbarr@ti.com>E<gt>, and radically simplified
	 with some information from Jochen Wiedmann E<lt>F<joe@ispsoft.de>E<gt>.
	 The template was then included in the DBI::DBD documentation by
	 Jonathan Leffler E<lt>F<jleffler@informix.com>E<gt>.



       The Driver.pm file defines the Perl module DBD::Driver for your driver.	It will define a
       package DBD::Driver along with some version information, some variable definitions, and a
       function driver() which will have a more or less standard structure.

       It will also define a package DBD::Driver::dr (with methods connect(), data_sources() and
       disconnect_all()), and a package DBD::Driver::db (which will define a function prepare()
       etc), and a package DBD::Driver::st with methods execute(), fetch() and the like.

       The Driver.pm file will also contain the documentation specific to DBD::Driver in the for-
       mat used by perldoc.

       Now let's take a closer look at an excerpt of File.pm as an example.  We ignore things
       that are common to any module (even non-DBI(D) modules) or really specific for the
       DBD::File package.

       The header
	   package DBD::File;

	   use strict;
	   use vars qw($err $errstr $state $drh);

	   $err = 0;		 # holds error code   for DBI::err
	   $errstr = "";	 # holds error string for DBI::errstr
	   $sqlstate = "";	 # holds SQL state for	  DBI::state

	 These variables are used for storing error states and messages.  However, it is crucial
	 to understand that you must not modify them directly; instead use the event method, see

	   $drh = undef;	 # holds driver handle once initialized

	 This is where the driver handle will be stored, once created. Note, that you may assume,
	 there's only one handle for your driver.

       The driver constructor
	   sub driver
	       return $drh if $drh;	 # already created - return same one
	       my ($class, $attr) = @_;

	       $class .= "::dr";

	       # not a 'my' since we use it above to prevent multiple drivers
	       $drh = DBI::_new_drh($class, {
		   'Name'	 => 'File',
		   'Version'	 => $VERSION,
		   'Err'	 => \$DBD::File::err,
		   'Errstr'	 => \$DBD::File::errstr,
		   'State'	 => \$DBD::File::state,
		   'Attribution' => 'DBD::File by Jochen Wiedmann',

	       return $drh;

	 The driver method is the driver handle constructor. It's a reasonable example of how DBI
	 implements its handles. There are three kinds: driver handles (typically stored in $drh,
	 from now on called "drh"), database handles (from now on called "dbh" or $dbh) and
	 statement handles, (from now on called "sth" or $sth).

	 The prototype of DBI::_new_drh is

	   $drh = DBI::_new_drh($class, $attr1, $attr2);

	 with the following arguments:

	     is typically your drivers class, e.g., "DBD::File::dr", passed as first argument to
	     the driver method.

	     is a hash ref to attributes like Name, Version, Err, Errstr State and Attributrion.
	     These are processed and used by DBI, you better not make any assumptions on them nor
	     should you add private attributes here.

	     This is another (optional) hash ref with your private attributes. DBI will leave
	     them alone.

	 The DBI::new_drh method and the driver method both return "undef" for failure (in which
	 case you must look at $DBI::err and $DBI::errstr, because you have no driver handle).

       The database handle constructor
	 The next lines of code look as follows:

	   package DBD::Driver::dr; # ====== DRIVER ======

	   $DBD::Driver::dr::imp_data_size = 0;

	 Note that no @ISA is needed here, or for the other DBD::Driver::* classes, because the
	 DBI takes care of that for you when the driver is loaded.

	 The database handle constructor is a driver method, thus we have to change the names-

	   sub connect
	       my ($drh, $dbname, $user, $auth, $attr) = @_;

	       # Some database specific verifications, default settings
	       # and the like following here. This should only include
	       # syntax checks or similar stuff where it's legal to
	       # 'die' in case of errors.

	       # create a 'blank' dbh (call superclass constructor)
	       my $dbh = DBI::_new_dbh($drh, {
		   'Name'	  => $dbname,
		   'USER'	  => $user,
		   'CURRENT_USER' => $user,

	       # Process attributes from the DSN; we assume ODBC syntax
	       # here, that is, the DSN looks like var1=val1;...;varN=valN

	       my $var;
	       foreach $var (split(/;/, $dbname)) {
		   if ($var =~ m/(.*?)=(,*)/) {
		       # Not !!! $dbh->{$var} = $val;
		       $dbh->STORE($var, $val);

	 This is mostly the same as in the driver handle constructor above.  The arguments are
	 described in the DBI man page. See DBI(3).  The constructor is called, returning a data-
	 base handle. The constructors prototype is

	   $dbh = DBI::_new_dbh($drh, $attr1, $attr2);

	 with the same arguments as in the driver handle constructor, the exception being $class
	 replaced by $drh.

	 Note the use of the STORE method for setting the dbh attributes.  That's because within
	 the driver code, the handle object you have is the 'inner' handle of a tied hash, not
	 the outer handle that the users of your driver have.

	 Because you have the inner handle, tie magic doesn't get invoked when you get or set
	 values in the hash. This is often very handy for speed when you want to get or set sim-
	 ple non-special driver-specific attributes.

	 However, some attribute values, such as those handled by the DBI like PrintError, don't
	 actually exist in the hash and must be read via $h->FETCH($attrib) and set via
	 $h->STORE($attrib, $value).  If in any doubt, use these methods.

       Error handling
	 It is quite likely that something fails in the connect method. With DBD::File for exam-
	 ple, you might catch an error when setting the current directory to something not exis-
	 tant by using the f_dir attribute.

	 To report an error, you use the "DBI::set_err" function/method:

	   $h->DBI::set_err($errcode, $errmsg);

	 This will ensure that the error is recorded correctly and that RaiseError and PrintError
	 etc are handled correctly.  Typically you'll always use the method instance, aka your
	 method's first argument.

	 As set_err always returns undef your error handling code can usually be simplified to
	 something like this:

	   return $h->DBI::set_err($errcode, $errmsg) if ...;

       Other driver handle methods
	 may follow here. In particular you should consider a data_sources method, and a (possi-
	 bly empty) disconnect_all method. See DBI(3).

       The statement handle constructor
	 There's nothing much new in the statement handle constructor.

	   package DBD::Driver::db; # ====== DATABASE ======

	   $DBD::Driver::db::imp_data_size = 0;

	   sub prepare
	       my ($dbh, $statement, @attribs) = @_;

	       # create a 'blank' sth
	       my $sth = DBI::_new_sth($dbh, {
		   'Statement' => $statement,

	       # Setup module specific data
	       $sth->STORE('driver_params', []);
	       $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));


	 This is still the same: Check the arguments and call the super class constructor
	 DBI::_new_sth. Note the prefix driver_ in the attribute names: It is required that your
	 private attributes are lowercased and use such a prefix. See the DBI manual.

	 Note that we parse the statement here in order to setup the attribute NUM_OF_PARAMS. We
	 could as well do this in the execute method below, the DBI specs explicitly allow to
	 defer this. However, one could not call bind_param in that case.

       Transaction handling
	 Pure Perl drivers will rarely support transactions. Thus you're commit and rollback
	 methods will typically be quite simple:

	   sub commit
	       my ($dbh) = @_;
	       if ($dbh->FETCH('Warn')) {
		   warn("Commit ineffective while AutoCommit is on");

	   sub rollback {
	       my ($dbh) = @_;
	       if ($dbh->FETCH('Warn')) {
		   warn("Rollback ineffective while AutoCommit is on");
	 Or even simpler, just use the default methods provided by the DBI that
	 do nothing except return undef.

	 The DBI's default begin_work method can be used by inheritance.

       The STORE and FETCH methods
	 These methods (that we have already used, see above) are called for you, whenever the
	 user does a

	   $dbh->{$attr} = $val;

	 or, respectively,

	   $val = $dbh->{$attr};

	 See perltie(1) for details on tied hash refs to understand why these methods are

	 The DBI will handle most attributes for you, in particular attributes like RaiseError or
	 PrintError. All you have to do handle your driver's private attributes and any
	 attributes, like AutoCommit, that the DBI can't handle for you. A good example might
	 look like this:

	   sub STORE
	       my ($dbh, $attr, $val) = @_;
	       if ($attr eq 'AutoCommit') {
		   # AutoCommit is currently the only standard attribute we have
		   # to consider.
		   if (!$val) { die "Can't disable AutoCommit"; }
		   return 1;
	       if ($attr =~ m/^driver_/) {
		   # Handle only our private attributes here
		   # Note that we could trigger arbitrary actions.
		   # Ideally we should catch unknown attributes.
		   $dbh->{$attr} = $val; # Yes, we are allowed to do this,
		   return 1;		 # but only for our private attributes
	       # Else pass up to DBI to handle for us
	       $dbh->SUPER::STORE($attr, $val);

	   sub FETCH
	       my ($dbh, $attr) = @_;
	       if ($attr eq 'AutoCommit') { return 1; }
	       if ($attr =~ m/^driver_/) {
		   # Handle only our private attributes here
		   # Note that we could trigger arbitrary actions.
		   return $dbh->{$attr}; # Yes, we are allowed to do this,
					 # but only for our private attributes
	       # Else pass up to DBI to handle

	 The DBI will actually store and fetch driver-specific attributes (with all lowercase
	 names) without warning or error, so there's actually no need to implement driver-spe-
	 cific any code in your FETCH and STORE methods unless you need extra logic/checks,
	 beyond getting or setting the value.

       Other database handle methods
	 may follow here. In particular you should consider a (possibly empty) disconnect method,
	 a quote method (if DBI's default isn't good for you).

       The execute method
	 This is perhaps the most difficult method because we have to consider parameter bindings
	 here. We present a simplified implementation by using the driver_params attribute from

	   package DBD::Driver::st;

	   $DBD::Driver::st::imp_data_size = 0;

	   sub bind_param
	       my ($sth, $pNum, $val, $attr) = @_;
	       my $type = (ref $attr) ? $attr->{TYPE} : $attr;
	       if ($type) {
		   my $dbh = $sth->{Database};
		   $val = $dbh->quote($sth, $type);
	       my $params = $sth->FETCH('driver_params');
	       $params->[$pNum-1] = $val;

	   sub execute
	       my ($sth, @bind_values) = @_;
	       my $params = (@bind_values) ?
		   \@bind_values : $sth->FETCH('driver_params');
	       my $numParam = $sth->FETCH('NUM_OF_PARAMS');
	       if (@$params != $numParam) { ... }
	       my $statement = $sth->{'Statement'};
	       for (my $i = 0;	$i < $numParam;  $i++) {
		   $statement =~ s/?/$params->[$i]/e;
	       # Do anything ... we assume that an array ref of rows is
	       # created and store it:
	       $sth->{'driver_data'} = $data;
	       $sth->{'driver_rows'} = @$data; # number of rows
	       $sth->STORE('NUM_OF_FIELDS') = $numFields;
	       @$data || '0E0';

	 Things you should note here: We setup the NUM_OF_FIELDS attribute here, because this is
	 essential for bind_columns to work. And we use attribute $sth-{'Statement'}> which we
	 have created within prepare. The attribute $sth-{'Database'}>, which is nothing else
	 than the dbh, was automatically created by DBI.

	 Finally note that we return the string '0E0' instead of the number 0, so that

	   if (!$sth->execute()) { die $sth->errstr }


       Fetching data
	 We need not implement the methods fetchrow_array, fetchall_arrayref, ... because these
	 are already part of DBI. All we need is the method fetchrow_arrayref:

	   sub fetchrow_arrayref
	       my ($sth) = @_;
	       my $data = $sth->FETCH('driver_data');
	       my $row = shift @$data;
	       if (!$row) { return undef; }
	       if ($sth->FETCH('ChopBlanks')) {
		   map { $_ =~ s/\s+$//; } @$row;
	       return $sth->_set_fbav($row);
	   *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref

	   sub rows { my ($sth) = @_; $sth->FETCH('driver_rows'); }

	 Note the use of the method _set_fbav: This is required so that bind_col and bind_columns

	 Fixing the broken implementation for correct handling of quoted question marks is left
	 as an exercise to the reader. :-)

       Statement attributes
	 The main difference between dbh and sth attributes is, that you should implement a lot
	 of attributes here that are required by the DBI: For example NAME, NULLABLE, TYPE, ...

	 Besides that the STORE and FETCH methods are mainly the same as above for dbh's.

       Other statement methods
	 A trivial "finish" method to discard the stored data and do $sth->SUPER::finish;

	 A "table_info" method to return details of available tables.

	 A "type_info_all" method to return details of supported types.

	 And perhaps some other methods that are not part of the DBI specs, in particular make
	 metadata available. Considering Tim's last articles do yourself a favour and follow the
	 ODBC driver.


       The test process should conform as closely as possibly to the Perl standard test harness.

       In particular, most of the tests should be run in the t sub-directory, and should simply
       produce an 'ok' when run under 'make test'.  For details on how this is done, see the
       Camel book and the section in Chapter 7, "The Standard Perl Library" on Test::Harness.

       The tests may need to adapt to the type of database which is being used for testing, and
       to the privileges of the user testing the driver.

       The DBD::Informix test code has to adapt in a number of places to the type of database to
       which it is connected as different Informix databases have different capabilities.

	       [...More info TBS...]

       Creating a new C/XS driver from scratch will always be a daunting task.	You can and
       should greatly simplify your task by taking a good reference driver implementation and
       modifying that to match the database product for which you are writing a driver.

       The de facto reference driver has been the one for DBD::Oracle, written by Tim Bunce who
       is also the author of the DBI package. The DBD::Oracle module is a good example of a
       driver implemented around a C-level API.

       Nowadays it it seems better to base on DBD::ODBC, another driver maintained by Tim and
       Jeff Urlwin, because it offers a lot of metadata and seems to become the guideline for the
       future development. (Also as DBD::Oracle digs deeper into the Oracle 8 OCI interface it'll
       get even more hairly than it is now.)

       The DBD::Informix driver is a good reference for a driver implemented using 'embedded
       SQL'. DBD::Ingres may also be worth a look.

	       [...More info TBS...]




       A minimal driver will typically contain 9 files plus some tests.  Assuming that your
       driver is called DBD::Driver, these files are:



       The Driver.pm file is the same as for Pure Perl modules, see above.  However, there are
       some subtle differences:

       o       The variables $DBD::File::dr|db|st::imp_data_size are not defined here, but in the
	       XS code, because they declare the size of certain C structures.

       o       Some methods are typically moved to the XS code, in particular prepare, execute,
	       disconnect, disconnect_all and the STORE and FETCH methods.

       o       Other methods are still part of "Driver.pm", but have callbacks in the XS code.

       Now let's take a closer look at an excerpt of Oracle.pm (around version 0.54, prior to
       Oracle 8 support) as an example.  We ignore things that are already discussed for Pure
       Perl drivers or really Oracle specific.

       The database handle constructor
	   sub connect
	       my ($drh, $dbname, $user, $auth) = @_;

	       # Some database specific verifications, default settings
	       # and the like following here. This should only include
	       # syntax checks or similar stuff where it's legal to
	       # 'die' in case of errors.

	       # create a 'blank' dbh (call superclass constructor)
	       my $dbh = DBI::_new_dbh($drh, {
		   'Name'	  => $dbname,
		   'USER'	  => $user,
		   'CURRENT_USER' => $user,
		   }) or return undef;

	       # Call Oracle OCI orlon func in Oracle.xs file
	       # and populate internal handle data.
	       DBD::Oracle::db::_login($dbh, $dbname, $user, $auth)
		   or return undef;


	 This is mostly the same as in the Pure Perl case, the exception being the use of the
	 private _login callback: This will really connect to the database. It is implemented in
	 Driver.xst (you should not implement it) and calls dbd_db_login6 from dbdimp.c. See
	 below for details.

	     *FIX ME* Discuss removing attributes from hash reference as an optimization to skip
	     later calls to $dbh->STORE made by DBI->connect.

       The statement handle constructor
	 There's nothing much new in the statement handle constructor. Like the connect method it
	 now has a C callback:

	   package DBD::Oracle::db; # ====== DATABASE ======
	   use strict;

	   sub prepare
	       my ($dbh, $statement, @attribs) = @_;

	       # create a 'blank' sth
	       my $sth = DBI::_new_sth($dbh, {
		   'Statement' => $statement,

	       # Call Oracle OCI oparse func in Oracle.xs file.
	       # (This will actually also call oopen for you.)
	       # and populate internal handle data.

	       DBD::Oracle::st::_prepare($sth, $statement, @attribs)
		   or return undef;



       Driver.xs should look something like this:

	 #include "Driver.h"


	 INCLUDE: Driver.xsi

	 MODULE = DBD::Driver	 PACKAGE = DBD::Driver::db

	 /* Non-standard dbh XS methods following here, if any.       */
	 /* Currently this includes things like _list_tables from     */
	 /* DBD::mSQL and DBD::mysql.				      */

	 MODULE = DBD::Driver	 PACKAGE = DBD::Driver::st

	 /* Non-standard sth XS methods following here, if any.       */
	 /* In particular this includes things like _list_fields from */
	 /* DBD::mSQL and DBD::mysql for accessing metadata.	      */

       Note especially the include of Driver.xsi here: DBI inserts stub functions for almost all
       private methods here which will typically do much work for you. Wherever you really have
       to implement something, it will call a private function in dbdimp.c: This is what you have
       to implement.


       Driver.h should look like this:


	 #include <DBIXS.h>	 /* installed by the DBI module  */

	 #include "dbdimp.h"

	 #include <dbd_xsh.h>	 /* installed by the DBI module  */

       Implementation header dbdimp.h

       This header file has two jobs:

       First it defines data structures for your private part of the handles.

       Second it defines macros that rename the generic names like dbd_db_login to database spe-
       cific names like ora_db_login. This avoids name clashes and enables use of different driv-
       ers when you work with a statically linked perl.

       It also will have the important task of disabling XS methods that you don't want to imple-

       Finally, the macros will also be used to select alternate implementations of some func-
       tions. For example, the currently defined "dbd_db_login" function is not passed the
       attribute hash. In future, if a dbd_db_login6 macro is defined (for a function with 6
       arguments), it will be used instead with the attribute hash passed at the sixth argument.

       People liked to just pick Oracle's dbdimp.c and use the same names, structures and types.
       I strongly recommend against that: At first glance this saves time, but your implementa-
       tion will be less readable.  It was just a hell when I had to separate DBI specific parts,
       Oracle specific parts, mSQL specific parts and mysql specific parts in DBD::mysql's
       dbdimp.h and dbdimp.c. (DBD::mysql was a port of DBD::mSQL which was based on DBD::Ora-
       cle.) This part of the driver is your exclusive part. Rewrite it from scratch, so it will
       be clean and short, in other words: A better piece of code. (Of course have an eye at
       other people's work.)

	 struct imp_drh_st {
	     dbih_drc_t com;	       /* MUST be first element in structure   */

	     /* Insert your driver handle attributes here */

	 struct imp_dbh_st {
	     dbih_dbc_t com;	       /* MUST be first element in structure   */

	     /* Insert your database handle attributes here */

	 struct imp_sth_st {
	     dbih_stc_t com;	       /* MUST be first element in structure   */

	     /* Insert your statement handle attributes here */

	 /*  Rename functions for avoiding name clashes; prototypes are  */
	 /*  in dbd_xst.h						 */
	 #define dbd_init	  ora_init
	 #define dbd_db_login6	  ora_db_login
	 #define dbd_db_do	  ora_db_do
	 ... many more here ...

	   *FIX ME* Should use hypothetical drv_ prefix instead of ora_ prefix.

       These structures implement your private part of the handles. You have to use the name
       imp_dbh_dr|_db|_st and the first field must be of type dbih_drc_t|_dbc_t|_stc_t and must
       be called "com". You should never access these fields directly, except of using the
       DBIc_xxx macros below.

       Implementation source dbdimp.c

       This is the main implementation file. I will drop a short note on any function here that's
       used in the Driver.xsi template and thus has to be implemented. Of course you can add pri-
       vate or better static functions here.

       Since Perl 5.6 requires support for function prototypes (ANSI or ISO or Standard C), you
       should write your code using function prototypes too.

	   #include "Driver.h"


	   void dbd_init(dbistate_t* dbistate)
	       DBIS = dbistate;  /*  Initialize the DBI macros	*/

	 dbd_init will be called when your driver is first loaded. These statements are needed
	 for use of the DBI macros. They will include your private header file dbdimp.h in turn.

	     *FIX ME* Is recommended practice to use the unmapped DBI-specified names or to use
	     your driver-specific function names in the source code?  DBD::Informix uses the
	     driver-specific names in the source; the header deals with the mapping.

	     ANSWER: Not very significant, but using the unmapped DBI-specified names (dbd_*)
	     makes it a little easier to compare code between drivers and eases discussions on
	     the dbi-dev mailing list.

	 You need a function to handle recording of errors. You can call it whatever you like,
	 but we'll call it "do_error" here.

	     *FIX ME* Should this be a file static function?  Why not?

	   void do_error(SV* h, int rc, char* what) {

	 Note that h is a generic handle, may it be a driver handle, a database or a statement


	 This macro will declare and initialize a variable imp_xxh with a pointer to your private
	 handle pointer. You may cast this to to imp_drh_t, imp_dbh_t or imp_sth_t.

	   SV *errstr = DBIc_ERRSTR(imp_xxh);
	   sv_setiv(DBIc_ERR(imp_xxh), (IV)rc);  /* set err early	 */
	   sv_setpv(errstr, what);
	   DBIh_EVENT2(h, ERROR_event, DBIc_ERR(imp_xxh), errstr);

	 Note the use of the macros DBIc_ERRSTR and DBIc_ERR for accessing the handles error
	 string and error code.

	 The macro DBIh_EVENT2 will ensure that the attributes RaiseError and PrintError work:
	 That's all what you have to deal with them. :-)

	   if (dbis->debug >= 2)
	       fprintf(DBILOGFP, "%s error %d recorded: %s\n",
		   what, rc, SvPV(errstr,na));

	 That's the first time we see how debug/trace logging works within a DBI driver.  Make
	 use of this as often as you can!

	   int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
			    char* user, char* auth, SV *attr);

	 This function will really connect to the database. The argument dbh is the database han-
	 dle. imp_dbh is the pointer to the handles private data, as is imp_xxx in do_error
	 above. The arguments dsn, user and auth correspond to the arguments of the driver han-
	 dles connect method.

	 You will quite often use database specific attributes here, that are specified in the
	 DSN. I recommend you parse the DSN within the connect method and pass them as \%attr
	 thru _login to dbd_db_login6.	Here's how you fetch them, as an example we use hostname
	 and port attributes:

	   SV** svp;
	   STRLEN len;
	   char* hostname;

	   if ( (svp = DBD_ATTRIB_GET_SVP(attr, "drv_hostname", 12)) && SvTRUE(*svp)) {
	       hostname = SvPV(*svp, len);
	       DBD__ATTRIB_DELETE(attr, "drv_hostname", 12); /* avoid later STORE */
	   } else {
	       hostname = "localhost";

	 Now you should really connect to the database. If you are successful (or even if you
	 fail, but you have allocated some resources), you should use the following macros:


	 This indicates that the driver (implementor) has allocated resources in the imp_dbh
	 structure and that the implementors private dbd_db_destroy function should be called
	 when the handle is destroyed.


	 This indicates that the handle has an active connection to the server and that the
	 dbd_db_disconnect function should be called before the handle is destroyed.

	 The dbd_db_login6 function should return TRUE for success, FALSE otherwise.

	   int dbd_db_commit(	SV* dbh, imp_dbh_t* imp_dbh );
	   int dbd_db_rollback( SV* dbh, imp_dbh_t* imp_dbh );

	 These are used for commit and rollback. They should return TRUE for success, FALSE for

	 The arguments dbh and imp_dbh are like above, I will omit describing them in what fol-
	 lows, as they appear always.

	 This is your private part of the disconnect method. Any dbh with the ACTIVE flag on must
	 be disconnected. (Note that you have to set it in dbd_db_connect above.)

	   int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);

	 The database handle will return TRUE for success, FALSE otherwise.  In any case it
	 should do a


	 before returning so DBI knows that dbd_db_disconnect was executed.

	 Note that there's noting to stop a dbh being disconnected while it still have active
	 children. If your database API reacts badly to trying to use an sth in this situation
	 then you'll need to add code like this to all sth methods:

	   if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth)))
	     return 0;

	   int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);

	 This function may be called at shutdown time. It should make best-efforts to disconnect
	 all database handles - if possible. Some databases don't support that, in which case you
	 can do nothing but return 'success'.

	 You guess what the return codes are? (Hint: See the last functions above ... :-)

	 This is your private part of the database handle destructor. Any dbh with the IMPSET
	 flag on must be destroyed, so that you can safely free resources. (Note that you have to
	 set it in dbd_db_connect above.)

	   void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)

	 The DBI Driver.xst code will have called dbd_db_disconnect for you, if the handle is
	 still 'active', before calling dbd_db_destroy.

	 Before returning the function must switch IMPSET to off, so DBI knows that the destruc-
	 tor was called.

	 A DBI handle doesn't keep references to its children. But children do keep references to
	 their parents. So a database handle won't be DESTROY'd until all it's children have been

	 This function handles

	 $dbh->{$key} = $value;

       Its prototype is:

	 int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
				 SV* valuesv);

       You do not handle all attributes; on the contrary, you should not handle DBI attributes
       here: Leave this to DBI. (There's one exception, AutoCommit, which you should care about.)

       The return value is TRUE, if you have handled the attribute or FALSE otherwise. If you are
       handling an attribute and something fails, you should call do_error, so DBI can raise
       exceptions, if desired.	If do_error returns, however, you have a problem: The user will
       never know about the error, because he typically will not check "$dbh->errstr".

       I cannot recommend a general way of going on, if do_error returns, but there are examples
       where even the DBI specification expects that you croak(). (See the AutoCommit method in

       If you have to store attributes, you should either use your private data structure
       imp_xxx, the handle hash (via (HV*)SvRV(dbh)), or use the private imp_data.

       The first is best for internal C values like integers or pointers and where speed is
       important within the driver. The handle hash is best for values the user may want to
       get/set via driver-specific attributes.	The private imp_data is an additional SV attached
       to the handle. You could think of it as an unnamed handle attribute. It's not normally

	 This is the counterpart of dbd_db_STORE_attrib, needed for

	 $value = $dbh->{$key};

       Its prototype is:

	 SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);

       Unlike all previous methods this returns an SV with the value. Note that you should nor-
       mally execute sv_2mortal, if you return a nonconstant value. (Constant values are
       &sv_undef, &sv_no and &sv_yes.)

       Note, that DBI implements a caching algorithm for attribute values.  If you think, that an
       attribute may be fetched, you store it in the dbh itself:

	 if (cacheit) /* cache value for later DBI 'quick' fetch? */
	     hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);

	 This is the private part of the prepare method. Note that you must not really execute
	 the statement here. You may, for example, preparse and validate the statement or do sim-
	 ilar things.

	 int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
			    SV* attribs);

       A typical, simple, possibility is to do nothing and rely on the perl perpare() code that
       set the Statement attribute on the handle. This attribute can then be used by dbd_st_exe-

       If the driver supports placeholders then the NUM_OF_PARAMS attribute must be set correctly
       by dbd_st_prepare:

	 DBIc_NUM_PARAMS(imp_sth) = ...

       If you can, you should also setup attributes like NUM_OF_FIELDS, NAME, ... here, but DBI
       doesn't require that. However, if you do, document it.

       In any case you should set the IMPSET flag, as you did in dbd_db_connect above:


	 This is where a statement will really be executed.

	 int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);

       Note, that you must be aware, that a statement may be executed repeatedly.  Also, you
       should not expect, that finish will be called between two executions, so you'll probably
       want code like:

	 if (DBIc_ACTIVE(imp_sth))
	     dbd_st_finish(h, imp_sth);

       If your driver supports binding of parameters (it should!), but the database doesn't, you
       must do it here. This can be done as follows:

	 SV *svp;
	 char* statement = DBD_ATTRIB_GET_PV(h, "Statement", 9, svp, "");
	 int numParam = DBIc_NUM_PARAMS(imp_sth);
	 int i;

	 for (i = 0; i < numParam; i++) {
	     char* value = dbd_db_get_param(sth, imp_sth, i);
	     /* Its your drivers task to implement dbd_db_get_param,	  */
	     /* it must be setup as a counterpart of dbd_bind_ph.	  */
	     /* Look for '?' and replace it with 'value'.  Difficult	  */
	     /* task, note that you may have question marks inside	  */
	     /* quotes and comments the like ...  :-(			  */
	     /* See DBD::mysql for an example. (Don't look too deep into  */
	     /* the example, you will notice where I was lazy ...)	  */

       The next thing is you really execute the statement.  Note that you must set the attributes
       NUM_OF_FIELDS, NAME, etc when the statement is successfully executed if the driver has not
       already done so.  They may be used even before a potential fetchrow.  In particular you
       have to tell DBI the number of fields, that the statement has, because it will be used by
       DBI internally.	Thus the function will typically ends with:

	 if (isSelectStatement) {
	     DBIc_NUM_FIELDS(imp_sth) = numFields;

       It is important that the ACTIVE flag only be set for "SELECT" statements (or any other
       statements that can return multiple sets of values from the database using a cursor-like
       mechanism).  See dbd_st_preparse and dbd_db_connect above for more explanations.

	 This function fetches a row of data. The row is stored in in an array, of SV's that DBI
	 prepares for you. This has two advantages: it is fast (you even reuse the SV's, so they
	 don't have to be created after the first fetchrow), and it guarantees that DBI handles
	 bind_cols for you.

       What you do is the following:

	 AV* av;
	 int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
	     is constant for this statement. There are drivers where this is
	     not the case! */
	 int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
	 int i;

	 if (!fetch_new_row_of_data(...)) {
	     ... /* check for error or end-of-data */
	     DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
	     return Nullav;
	 /* get the fbav (field buffer array value) for this row       */
	 /* it is very important to only call this after you know      */
	 /* that you have a row of data to return.		       */
	 av = DBIS->get_fbav(imp_sth);
	 for (i = 0; i < numFields; i++) {
	     SV* sv = fetch_a_field(..., i);
	     if (chopBlanks && SvOK(sv) && type_is_blank_padded(field_type[i])) {
		 /*  Remove white space from end (only) of sv  */
	     sv_setsv(AvARRAY(av)[i], sv); /* Note: (re)use! */
	 return av;

       There's no need to use a fetch_a_field function returning an SV*.  It's more common to use
       your database API functions to fetch the data as character strings and use code like this:

	 sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);

       NULL values must be returned as undef. You can use code like this:


       The function returns the AV prepared by DBI for success or "Nullav" otherwise.

	   *FIX ME* Discuss what happens when there's no more data to fetch.  Are errors permit-
	   ted if another fetch occurs after the first fetch that reports no more data. (Permit-
	   ted, not required.)

	      This function can be called if the user wishes to indicate that no more rows will
	      be fetched even if the server has more rows to offer.  See the DBI docs for more
	      background details.

       All it needs to do is turn off the Active flag for the sth.  It will only be called by
       Driver.xst code, if the driver has set ACTIVE to on for the sth.

       Minimal example:

	 int dbd_st_finish3(SV* sth, imp_sth_t* imp_sth, int from_destroy) {
	     if (!DBIc_ACTIVE(imp_sth))
		 return 1;
	     /* close cursor or equivalent action */
	     return 1;

       The from_destroy parameter is true if dbd_st_finish3 is being called from DESTROY - and so
       the statement is about to be destroyed. For many drivers there's no point in doing any-
       thing more than turing of the Active flag in this case.

       The function returns TRUE for success, FALSE otherwise.

	      This function is the private part of the statement handle destructor.

	 void dbd_st_destroy(SV* sth, imp_sth_t* imp_sth) {
	     ... /* any clean-up that's needed */
	     DBIc_IMPSET_off(imp_sth); /* let DBI know we've done it   */

       The DBI Driver.xst code will call dbd_st_finish for you, if the sth has the ACTIVE flag
       set, before calling dbd_st_destroy.

	      These functions correspond to dbd_db_STORE|FETCH attrib above, except that they are
	      for statement handles. See above.

	 int dbd_st_STORE_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv,
				 SV* valuesv);
	 SV* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);

	      This function is internally used by the bind_param method, the bind_param_inout
	      method and by the DBI Driver.xst code if "execute" is called with any bind parame-

	 int dbd_bind_ph (SV *sth, imp_sth_t *imp_sth, SV *param,
			  SV *value, IV sql_type, SV *attribs,
			  int is_inout, IV maxlen);

       The param argument holds an IV with the parameter number (1, 2, ...).  The value argument
       is the parameter value and sql_type is its type.

       If your driver does not support bind_param_inout then you should ignore maxlen and croak
       if is_inout is TRUE.

       If your driver does support bind_param_inout then you should note that value is the SV
       after dereferencing the reference passed to bind_param_inout.

       In drivers of simple databases the function will, for example, store the value in a param-
       eter array and use it later in dbd_st_execute.  See the DBD::mysql driver for an example.

       Implementing bind_param_inout support

       To provide support for parameters bound by reference rather than by value, the driver must
       do a number of things.  First, and most importantly, it must note the references and stash
       them in its own driver structure.  Secondly, when a value is bound to a column, the driver
       must discard any previous reference bound to the column.  On each execute, the driver must
       evaluate the references and internally bind the values resulting from the references.
       This is only applicable if the user writes:


       If the user writes:


       then DBI automatically calls the binding code for each element of @values.  These calls
       are indistinguishable from explicit user calls to bind_param.


       This is exactly as in the Pure Perl case. To be honest, the above Makefile.PL contains
       some things that are superfluous for Pure Perl drivers. :-)

       The DBI code implements the majority of the methods which are accessed using the notation
       DBI->function(), the only exceptions being DBI->connect() and DBI->data_sources() which
       require support from the driver.

       The DBI code implements the following documented driver, database and statement functions
       which do not need to be written by the DBD driver writer.

	   The default implementation of this function prepares, executes and destroys the state-
	   ment.  This can be replaced if there is a better way to implement this, such as EXE-
	   CUTE IMMEDIATE which can sometimes be used if there are no parameters.

	   The DBD driver does not need to worry about these routines at all.

	   This attribute needs to be honured during fetch operations, but does not need to be
	   handled by the attribute handling code.

	   The DBD driver does not need to worry about this attribute at all.

	   The DBD driver does not need to worry about this attribute at all.

	   Assuming the driver uses the DBIS->get_fbav() function (C drivers, see below), or the
	   $sth->_set_fbav($data) method (Perl drivers) the driver does not need to do anything
	   about this routine.

	   Regardless of whether the driver uses DBIS->get_fbav(), the driver does not need to do
	   anything about this routine as it simply iteratively calls $sth->bind_col().

       The DBI code implements a default implementation of the following functions which do not
       need to be written by the DBD driver writer unless the default implementation is incorrect
       for the Driver.

	   This should only be written if the database does not accept the ANSI SQL standard for
	   quoting strings, with the string enclosed in single quotes and any embedded single
	   quotes replaced by two consecutive single quotes.

	   For the two argument form of quote, you need to implement the "type_info" method to
	   provide the information that quote needs.

	   This should be implemented as a simple efficient way to determine whether the connec-
	   tion to the database is still alive. Typically code like this:

	     sub ping {
		 my $dbh = shift;
		 $sth = $dbh->prepare_cached(q{
		     select * from A_TABLE_NAME where 1=0
		 }) or return 0;
		 $sth->execute or return 0;
		 return 1;

	   where A_TABLE_NAME is the name of a table that always exists (such as a database sys-
	   tem catalogue).

       Study Oraperl.pm (supplied with DBD::Oracle) and Ingperl.pm (supplied with DBD::Ingres)
       and the corresponding dbdimp.c files for ideas.

       Note that the emulation code sets $dbh->{CompatMode} = 1; for each connection so that the
       internals of the driver can implement behaviour compatible with the old interface when
       dealing with those handles.

       Setting emulation perl variables

       For example, ingperl has a $sql_rowcount variable. Rather than try to manually update this
       in Ingperl.pm it can be done faster in C code.  In dbd_init():

	 sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);

       In the relevant places do:

	 if (DBIc_COMPAT(imp_sth))     /* only do this for compatibility mode handles */
	     sv_setiv(sql_rowcount, the_row_count);

       The imp_xyz_t types

       Any handle has a corresponding C structure filled with private data.  Some of this data is
       reserved for use by DBI (except for using the DBIc macros below), some is for you. See the
       description of the dbdimp.h file above for examples. The most functions in dbdimp.c are
       passed both the handle "xyz" and a pointer to "imp_xyz". In rare cases, however, you may
       use the following macros:

	 Given a function argument dbh, declare a variable imp_dbh and initialize it with a
	 pointer to the handles private data. Note: This must be a part of the function header,
	 because it declares a variable.

	 Likewise for statement handles.

	 Given any handle, declare a variable imp_xxx and initialize it with a pointer to the
	 handles private data. It is safe, for example, to cast imp_xxx to "imp_dbh_t*", if
	 DBIc_TYPE(imp_xxx) == DBIt_DB.  (You can also call sv_derived_from(h, "DBI::db"), but
	 that's much slower.)

	 Given a imp_sth, declare a variable imp_dbh and initialize it with a pointer to the par-
	 ent database handles implementors structure.

       Using DBIc_IMPSET_on

       The driver code which initializes a handle should use DBIc_IMPSET_on() as soon as its
       state is such that the cleanup code must be called.  When this happens is determined by
       your driver code.

       Failure to call this can lead to corruption of data structures.	For example,
       DBD::Informix maintains a linked list of database handles in the driver, and within each
       handle, a linked list of statements.  Once a statement is added to the linked list, it is
       crucial that it is cleaned up (removed from the list).  When DBIc_IMPSET_on() was being
       called too late, it was able to cause all sorts of problems.

       Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()

       Once upon a long time ago, the only way of handling the internal DBI boolean
       flags/attributes was through macros such as:

	 DBIc_WARN	 DBIc_WARN_on	     DBIc_WARN_off

       Each of these took an imp_xxh pointer as an argument.

       Since then, new attributes have been added such as ChopBlanks, RaiseError and PrintError,
       and these do not have the full set of macros.  The approved method for handling these is
       now the four macros:

	 DBIc_is(imp, flag)
	 DBIc_has(imp, flag)	an alias for DBIc_is
	 DBIc_on(imp, flag)
	 DBIc_off(imp, flag)

       Consequently, the DBIc_XXXXX family of macros is now mostly deprecated and new drivers
       should avoid using them, even though the older drivers will probably continue to do so for
       quite a while yet. However...

       There is an important exception to that. The ACTIVE and IMPSET flags should be set via the
       DBIc_ACTIVE_on and DBIc_IMPSET_on macros, and unset via the DBIc_ACTIVE_off and
       DBIc_IMPSET_off macros.

       Using DBIS->get_fbav()

       The $sth->bind_col() and $sth->bind_columns() documented in the DBI specification do not
       have to be implemented by the driver writer becuase DBI takes care of the details for you.
       However, the key to ensuring that bound columns work is to call the function
       DBIS->get_fbav() in the code which fetches a row of data.  This returns an AV, and each
       element of the AV contains the SV which should be set to contain the returned data.

       The above is for C drivers only. The Perl equivalent is the $sth->_set_fbav($data) method,
       as described in the part on Pure Perl drivers.

       This is definitely an open subject. It can be done, as demonstrated by the DBD::File
       driver, but it is not as simple as one might think.

       (Note that this topic is different from subclassing the DBI. For an example of that, see
       the t/subclass.t file supplied with the DBI.)

       The main problem is that the dbh's and sth's that your connect and prepare methods return
       are not instances of your DBD::Driver::db or DBD::Driver::st packages, they are not even
       derived from it.  Instead they are instances of the DBI::db or DBI::st classes or a
       derived subclass. Thus, if you write a method mymethod and do a


       then the autoloader will search for that method in the package DBI::db.	Of course you can
       instead to a


       and that will indeed work, even if mymethod is inherited, but not without additional work.
       Setting @ISA is not sufficient.

       Overwriting methods

       The first problem is, that the connect method has no idea of subclasses. For example, you
       cannot implement base class and subclass in the same file: The install_driver method wants
       to do a

	 require DBD::Driver;

       In particular, your subclass has to be a separate driver, from the view of DBI, and you
       cannot share driver handles.

       Of course that's not much of a problem. You should even be able to inherit the base
       classes connect method. But you cannot simply overwrite the method, unless you do some-
       thing like this, quoted from DBD::CSV:

	 sub connect ($$;$$$) {
	     my ($drh, $dbname, $user, $auth, $attr) = @_;

	     my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
	     if (!exists($this->{csv_tables})) {
		 $this->{csv_tables} = {};


       Note that we cannot do a

	 $srh->SUPER::connect($dbname, $user, $auth, $attr);

       as we would usually do in a an OO environment, because $drh is an instance of DBI::dr. And
       note, that the connect method of DBD::File is able to handle subclass attributes. See the
       description of Pure Perl drivers above.

       It is essential that you always call superclass method in the above manner. However, that
       should do.

       Attribute handling

       Fortunately the DBI specs allow a simple, but still performant way of handling attributes.
       The idea is based on the convention that any driver uses a prefix driver_ for its private
       methods. Thus it's always clear whether to pass attributes to the super class or not.  For
       example, consider this STORE method from the DBD::CSV class:

	 sub STORE {
	     my ($dbh, $attr, $val) = @_;
	     if ($attr !~ /^driver_/) {
		 return $dbh->DBD::File::db::STORE($attr, $val);
	     if ($attr eq 'driver_foo') {

       write_getinfo_pm generates a DBD::<foo>::GetInfo package.


	 perl -MDBI::DBD -e write_getinfo_pm dbi:ODBC:foo_db username password > DBD/<foo>/GetInfo.pm


	 perl -MDBI::DBD -e 'write_getinfo_pm("dbi:ODBC:foo_db","username","password")' > DBD/<foo>/GetInfo.pm

       This method generates a DBD::<foo>::GetInfo package from the data source you specified in
       the parameter list or in the environment variable DBI_DSN.  DBD::<foo>::GetInfo should
       help a DBD author implementing the DBI get_info() method.  Because you are just creating
       this package, it's very unlikly that DBD::<foo> already provides a good implementation for
       get_info(). Thus you will probable connect via DBD::ODBC.

       If you connect via DBD::ODBC, you should use version 0.38 or greater;

       Please have a critical look at the data returned! ODBC driver vary dramatically in their

       The generator assumes that most values are static and places these values directly in the
       %info hash. A few examples show the use of CODE references and the implementation via sub-
       routines.  It's very likely that you have to write additional subroutines for values
       depending on the session state or server version, e.g. SQL_DBMS_VER.

       A possible implementation of DBD::<foo>::get_info() may look like:

	 sub get_info {
	   my($dbh, $info_type) = @_;
	   require DBD::<foo>::GetInfo;
	   my $v = $DBD::<foo>::GetInfo::info{int($info_type)};
	   $v = $v->($dbh) if ref $v eq 'CODE';
	   return $v;

       Please replace <foo> with the name of your driver.

       Jonathan Leffler <jleffler@us.ibm.com> (previously <jleffler@informix.com>), Jochen Wied-
       mann <joe@ispsoft.de>, Steffen Goeldner <s.goeldner@eurodata.de>, and Tim Bunce

perl v5.8.0				    2002-11-29				      DBI::DBD(3)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 11:04 PM.