This is Info file pm.info, produced by Makeinfo version 1.68 from the input file bigpm.texi.  File: pm.info, Node: DBI/FAQ, Next: DBIx/Abstract, Prev: DBD/mysql, Up: Module List The Frequently Asked Questions for the Perl5 Database Interface *************************************************************** NAME ==== DBI::FAQ - The Frequently Asked Questions for the Perl5 Database Interface perldoc DBI::FAQ VERSION ======= This document is currently at version *0.38*, as of *February 8th, 2000*. DESCRIPTION =========== This document serves to answer the most frequently asked questions on both the DBI Mailing Lists and personally to members of the DBI development team. Basic Information & Information Sources ======================================= 1.1 What is DBI, DBperl, Oraperl and *perl? ------------------------------------------- To quote Tim Bunce, the architect and author of DBI: ``DBI is a database access Application Programming Interface (API) for the Perl Language. The DBI API Specification defines a set of functions, variables and conventions that provide a consistent database interface independant of the actual database being used.'' In simple language, the DBI interface allows users to access multiple database types transparently. So, if you connecting to an Oracle, Informix, mSQL, Sybase or whatever database, you don't need to know the underlying mechanics of the 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. *Please note*, the author's listed here generally *do not* maintain the DBI module for the same database. These email addresses are unverified and should only be used for queries concerning the perl4 modules listed below. DBI driver queries should be directed to the *dbi-users* mailing list. Module Name Database Required Author DBI ----------- ----------------- ------ --- Sybperl Sybase Michael Peppler DBD::Sybase Oraperl Oracle 6 & 7 Kevin Stock DBD::Oracle Ingperl Ingres Tim Bunce & DBD::Ingres Ted Lemon Interperl Interbase Buzz Moschetti DBD::Interbase Uniperl Unify 5.0 Rick Wargo None Pgperl Postgres Igor Metz DBD::Pg Btreeperl NDBM John Conover SDBM? Ctreeperl C-Tree John Conover None Cisamperl Informix C-ISAM Mathias Koerber None Duaperl X.500 Directory Eric Douglas None User Agent However, some DBI 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 API calls into DBI calls and executes them through the DBI 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 DBI Specification. It's use is being deprecated in favour of *DBD::mSQL*. *Msqlperl* may be downloaded from CPAN *via*: http://www.perl.com/cgi-bin/cpan_mod?module=Msqlperl 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 DBI and drivers. CPAN may be accessed *via* Tom Christiansen's splendid *CPAN multiplexer* program located at: http://www.perl.com/CPAN/ For more specific version information and exact URLs of drivers, please see the DBI drivers list and the DBI module pages which can be found on: http://www.symbolstone.org/technology/perl/DBI This list is automatically generated on a nightly basis from CPAN and should be up-to-date. 1.3. Where can I get more information? -------------------------------------- There are a few information sources on DBI. *"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 via O'Reilly & Associates http://www.oreilly.com/catalog/perldbi or Amazon http://www.amazon.com/exec/obidos/ASIN/1565926994/dbi *POD documentation* PODs are chunks of documentation usually embedded within perl programs that document the code "*in place*", providing a useful resource for programmers and users of modules. POD for DBI and drivers is beginning to become more commonplace, and documentation for these modules can be read with the 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 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: http://www.symbolstone.org/technology/perl/DBI 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* http://www.symbolstone.org/technology/perl/DBI/tidbits There are a series of occasional rambles from various people on the DBI mailing lists who, in an attempt to clear up a simple point, end up drafting fairly comprehensive documents. These are quite often varying in quality, but do provide some insights into the workings of the interfaces. Articles A list of articles discussing the DBI can be found on the DBI WWW page at: http://www.symbolstone.org/technology/perl/DBI 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: http://www.symbolstone.org/technology/perl/DBI Mailing Lists There are three mailing lists for DBI run by Ted Lemon. These can all be subscribed to and unsubscribed from *via* the World Wide Web at the URL of: http://www.isc.org/dbi-lists.html The lists that users may participate in are: *dbi-announce* This mailing list is for announcements only. Very low traffic. The announcements are usually posted on the main DBI WWW page. If you cannot successfully use the form on the above WWW page, please subscribe to the list in the following manner: Email: 'dbi-announce-request@isc.org' with a message body of 'subscribe' *dbi-dev* This mailing list is intended for the use of developers discussing ideas and concepts for the DBI interface, API and driver mechanics. Only any use for developers, or interested parties. Low traffic. If you cannot successfully use the form on the above WWW page, please subscribe to the list in the following manner: Email: 'dbi-dev-request@isc.org' with a message body of 'subscribe' *dbi-users* This mailing list is a general discussion list used for bug reporting, problem discussion and general enquiries. Medium traffic. If you cannot successfully use the form on the above WWW page, please subscribe to the list in the following manner: Email: 'dbi-users-request@isc.org' with a message body of 'subscribe' *Mailing List Archives* *US Mailing List Archives* http://outside.organic.com/mail-archives/dbi-users/ Searchable hypermail archives of the three mailing lists, and some of the much older traffic have been set up for users to browse. *European Mailing List Archives* http://www.rosat.mpe-garching.mpg.de/mailing-lists/PerlDB-Interest As per the US archive above. Compilation Problems ==================== 2.1. Compilation problems or "It fails the test!" ------------------------------------------------- First off, consult the README 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 README files for each driver in advance online at: http://www.symbolstone.org/technology/perl/DBI If it's a known problem, you'll probably have to wait till it gets fixed. If you're *really* needing it fixed, try the following: *Attempt to fix it yourself* This technique is generally not recommended to the faint-hearted. If you do think you have managed to fix it, then, send a patch file ( context diff ) to the author with an explanation of: * 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: http://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 DBI is a 'high level' interface that, like Perl itself, strives to make the simple things easy while still making the hard things possible. The ODBC is a 'low level' interface. All nuts-bolts-knobs-and-dials. Now there's an ODBC driver for the DBI (DBD::ODBC) the "What's the difference" question is more usefully rephrased as: Chapter 7 of "Programming the Perl DBI" covers this topic in far more detail and should be consulted. 3.2 What's the difference between Win32::ODBC and DBD::ODBC? ------------------------------------------------------------ The DBI, and thus DBD::ODBC, has a different philosophy from the Win32::ODBC module: The Win32::ODBC module is a 'thin' layer over the low-level ODBC API. The DBI defines a simpler 'higher level' interface. The Win32::ODBC module gives you access to more of the ODBC API. The DBI and DBD::ODBC give you access to only the essentials. (But, unlike Win32::ODBC, the DBI and DBD::ODBC 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 DBI and DBD::ODBC are very portable and work on Win32 and Unix. The DBI and DBD::ODBC 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 DBI and DBD::ODBC are faster than Win32::ODBC on Win32 and are trivially portable to other supported database types. The DBI offers optional automatic printing or die()ing on errors which makes applications simpler and more robust. The current DBD::ODBC driver version 0.16 is new and not yet fully stable. A new release is due soon [relative to the date of the next TPJ issue :-] and will be much improved and offer more ODBC functionality. To summarise: The Win32::ODBC module is your best choice if you need access to more of the ODBC API than the DBI gives you. Otherwise, the DBI and DBD::ODBC combination may be your best bet. Chapter 7 of "Programming the Perl DBI" 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 DBI and *DBD::ODBC* 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 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 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 *DBD::ODBC* driver. 3.5 Is the a DBD for <*insert favourite database here*>? -------------------------------------------------------- Is is listed on the DBI drivers page? http://www.symbolstone.org/technology/perl/DBI If not, no. A complete absence of a given database driver from that page means that no-one has announced any intention to work on it, not that such a driver is impossible to write. A corollary of the above statement implies that if you see an announcement for a driver not on the above page, there's a good chance it's not actually a DBI driver, and may not conform to the specifications. Therefore, questions concerning problems with that code should not really be addressed to the DBI Mailing Lists. 3.6 What's DBM? And why should I use DBI instead? ------------------------------------------------- Extracted from "*DBI - The Database Interface for Perl 5*": ``UNIX was originally blessed with simple file-based ``databases'', namely the dbm system. dbm lets you store data in files, and retrieve that data quickly. However, it also has serious drawbacks. File Locking The dbm systems did not allow particularly robust file locking capabilities, nor any capability for correcting problems arising through simultaneous writes [ to the database ]. Arbitrary Data Structures The dbm systems only allows a single fixed data structure: key-value pairs. That value could be a complex object, such as a [ C ] struct, but the key had to be unique. This was a large limitation on the usefulness of dbm systems. However, dbm systems still provide a useful function for users with simple datasets and limited resources, since they are fast, robust and extremely well-tested. Perl modules to access dbm systems have now been integrated into the core Perl distribution via the AnyDBM_File module.'' To sum up, DBM is a perfectly satisfactory solution for essentially read-only databases, or small and simple datasets. However, for more scaleable dataset handling, not to mention robust transactional locking, users are recommended to use a more powerful database engine *via* DBI. Chapter 2 of "Programming the Perl DBI" discusses DBM 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 WWW site at: http://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. http://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 RDBMS*. Oracle's WWW site is an excellent source of more information. http://www.oracle.com *Informix* is another high-end RDBMS that is worth considering. There are several differences between Oracle and Informix which are too complex for this document to detail. Information on Informix can be found on their WWW site at: http://www.informix.com In the case of WWW fronted applications, *mSQL* may be a better option due to slow connection times between a CGI script and the Oracle RDBMS and also the amount of resource each Oracle connection will consume. *mSQL* is lighter resource-wise and faster. These views are not necessarily representative of anyone else's opinions, and do not reflect any corporate sponsorship or views. They are provided *as-is*. 3.8 Is <*insert feature here*> supported in DBI? ------------------------------------------------ Given that we're making the assumption that the feature you have requested is a non-standard database-specific feature, then the answer will be no. DBI reflects a generic API that will work for most databases, and has no database-specific functionality. However, driver authors may, if they so desire, include hooks to database-specific functionality through the `func()' method defined in the DBI API. Script developers should note that use of functionality provided *via* the `func()' methods is very unlikely to be portable across databases. Programming Questions ===================== 4.1 Is DBI any use for CGI programming? --------------------------------------- In a word, yes! DBI is hugely useful for CGI programming! In fact, I would tentatively say that CGI programming is one of two top uses for DBI. DBI confers the ability to CGI programmers to power WWW-fronted databases to their users, which provides users with vast quantities of ordered data to play with. DBI also provides the possibility that, if a site is receiving far too much traffic than their database server can cope with, they can upgrade the database server behind the scenes with no alterations to the CGI scripts. 4.2 How do I get faster connection times with DBD::Oracle and CGI? ------------------------------------------------------------------ Contributed by John D. Groenveld The Apache `httpd' maintains a pool of `httpd' children to service client requests. Using the Apache mod_perl module by *Doug MacEachern*, the perl interpreter is embedded with the `httpd' children. The CGI, DBI, and your other favorite modules can be loaded at the startup of each child. These modules will not be reloaded unless changed on disk. For more information on Apache, see the Apache Project's WWW site: http://www.apache.org The mod_perl module can be downloaded from CPAN *via*: http://www.perl.com/cgi-bin/cpan_mod?module=Apache 4.3 How do I get persistent connections with DBI and CGI? --------------------------------------------------------- Contributed by John D. Groenveld Using Edmund Mergl's *Apache::DBI* module, database logins are stored in a hash with each of these `httpd' child. If your application is based on a single database user, this connection can be started with each child. Currently, database connections cannot be shared between `httpd' children. *Apache::DBI* can be downloaded from CPAN *via*: http://www.perl.com/cgi-bin/cpan_mod?module=Apache::DBI 4.4 "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 WWW server to pass-through certain environment variables to your CGI scripts. 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. The "Idiot's Guide To Solving Perl / CGI Problems" can be located at: http://www.perl.com/perl/faq/index.html as can the "Perl CGI Programming FAQ". Read *BOTH* these documents carefully! 4.5 How do I get the number of rows returned from a SELECT statement? --------------------------------------------------------------------- Count them. Read the DBI 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 DBI, as of version 1.02, does not yet support multi-threading so it would be unsafe to let more than one thread enter the DBI at the same time. It is expected that some future version of the DBI will at least be thread-safe (but not thread-hot) by automatically blocking threads intering the DBI while it's already in use. For some OCI example code for Oracle that has multi-threaded SELECT statements, see: http://www.symbolstone.org/technology/oracle/oci/orathreads.tar.gz 5.2 How do I handle BLOB data with DBI? --------------------------------------- Handling BLOB data with the DBI is very straight-forward. BLOB columns are specified in a SELECT statement as per normal columns. However, you also need to specify a maximum BLOB size that the database handle 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 provided no column values were larger than the specified value. If the BLOB data is longer than the value of `LongReadLen', then an error will occur. However, the DBI provides an additional piece of functionality that will automatically truncate the fetched BLOB to the size of `LongReadLen' if it is longer. This does not cause an error to occur, but may make your fetched BLOB data useless. This behaviour is regulated by the `LongTruncOk' attribute which is defaultly set to a false value ( thus making overlong BLOB fetches fail ). ### Set BLOB handling such that it's 16Kb and can be truncated $dbh->{LongReadLen} = 16384; $dbh->{LongTruncOk} = 1; Truncation of BLOB data may not be a big deal in cases where the BLOB contains run-length encoded data, but data containing checksums at the end, for example, a ZIP file, would be rendered useless. =head2 5.3 How can I invoke stored procedures with DBI? The DBI 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 SQL statements - and the DBI 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 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 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 DBI Specification. Chapter 6 of "Programming the Perl DBI" discusses transaction handling within the context of DBI in more detail. 5.7 How are NULL values handled by DBI? --------------------------------------- NULL values in DBI are specified to be treated as the value undef. NULLs can be inserted into databases as NULL, for example: $rv = $dbh->do( "INSERT INTO table VALUES( NULL )" ); but when queried back, the NULLs should be tested against undef. This is standard across all drivers. 5.8 What are these `func()' methods all about? ---------------------------------------------- The `func()' method is defined within DBI as being an entry point for database-specific functionality, *eg*, the ability to create or drop databases. Invoking these driver-specific methods is simple, for example, to invoke a `createDatabase' method that has one argument, we would write: $rv =$dbh->func( 'argument', 'createDatabase' ); Software developers should note that the `func()' methods are non-portable between databases. 5.9 Is DBI Year 2000 Compliant? ------------------------------- DBI has no knowledge of understanding of what dates are. Therefore, DBI 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 FAQ at: http://www.perl.com/CPAN/doc/FAQs/FAQ/PerlFAQ.html Support and Training ==================== The Perl5 Database Interface is *FREE* software. IT COMES WITHOUT WARRANTY OF ANY KIND. See the DBI README for more details. However, some organizations are providing either technical support or training programs on DBI. The present author has no knowledge as to the quality of these services. The links are included for reference purposes only 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: http://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: http://www.westlake.com/training for more details. Other References ================ In this section, we present some miscellaneous WWW links that may be of some interest to DBI users. These are not verified and may result in unknown sites or missing documents. http://www-ccs.cs.umass.edu/db.html http://www.odmg.org/odmg93/updates_dbarry.html http://www.jcc.com/sql_stnd.html AUTHOR ====== Alligator Descartes <*http://www.symbolstone.org/descarte/contact.html*>. 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 AUTHOR and COPYRIGHT sections ). Requests for other distribution rights, including incorporation into commercial products, such as books, magazine articles or CD-ROMs should be made to Alligator Descartes <*http://www.symbolstone.org/descarte/contact.html*>.  File: pm.info, Node: DBIx/Abstract, Next: DBIx/AnyDBD, Prev: DBI/FAQ, Up: Module List DBI SQL abstraction ******************* NAME ==== DBIx::Abstract - DBI SQL abstraction SYNOPSIS ======== use DBIx::Abstract; $db = DBIx::Abstract->connect({ driver=>'mydriver', host=>'myhost.org', dbname=>'mydb', user=>'myuser', password=>'mypassword', }); if ($db->select('*','table')->rows) { while ($data = $db->fetchrow_hashref) { ... } } ($name) = $db->select('name','table',{id=>$id})->fetchrow_array; *** $db = DBIx::Abstract->connect( { driver=>'csv', f_name=>'foo/' } ); *** $db = DBIx::Abstract->connect({ dsn=>'dbi:someotherdb:so_db_name=mydb', user=>'myuser', password=>'mypassword', }); DESCRIPTION =========== This module provides methods for doing manipulating database tables This module provides methods retrieving and storing data in SQL databases. It provides methods for all of the more important SQL commands (like SELECT, INSERT, REPLACE, UPDATE, DELETE). It endeavors to produce an interface that will be intuitive to those already familiar with SQL. Notable features include: * data_source generation for some DBD drivers. * Can check to make sure the connection is not stale and reconnect if it is. * Controls statement handles for you. * Can delay writes. * Generates complex where clauses from hashes and arrays. * Shortcuts (convenience functions) for some common cases. (Like select_all_to_hashref.) METHODS ======= Unless otherwise mentioned all methods return the database handle. connect ------- `connect($connect_config | $dbihandle [,$options])' CONSTRUCTOR Open a connection to a database as configured by $connect_config. $connect_config can either be a scalar, in which case it is a DBI data source, or a reference to a hash with the following keys: dsn -- The data source to connect to your database OR, DBIx::Abstract will try to generate it if you give these instead: driver -- DBD driver to use (defaults to mysql) host -- Host of database server port -- Port of database server dbname -- Name of database Username and password are always valid. user -- Username to connect as password -- Password for user Alternatively you can pass in a DBI handle directly. This will disable the methods "reconnect" and "ensure_connection" as they rely on connection info not available on a DBI handle. Options is a hash reference. Each key/value pair is passed on to the opt method. clone ----- This clones the object. For those times when you need a second connection to the same DB. If you need a second connection to a different DB, create a new object with 'connect'. This operation is logged at level 5 with the message "Cloned." connected --------- Check to see if this object is connected to a database. It checks to see if it has a database handle and if that handle's "Active" attribute is true. reconnect --------- If the object is not connected to a database it will reconnect using the same parameters connect was originally called with. ensure_connection ----------------- Makes sure that the object is connect to a database. Makes sure that the connect is active (by sending a "SELECT 1"). If there is no connection, or the connection is not active then it tries to reconnect. If it fails to reconnect then it dies. opt --- ($key[,$value]) ({key=>$key[,value=>$value]) Set option $key to $value. Available keys are: loglevel (default 0) 0 -- Fatal errors only 1 -- Modifications 2 -- And selects 3 -- And user created queries 4 -- And results of queries 5 -- And other misc commands 6 -- Internals of commands logfile (default undef) Log file delaymods (default false) Delay making modifications to the database until run_delayed is run. AutoCommit This works just like the DBI 'AutoCommit', except that it issues a warning (instead of dieing) if you give it bad data. useCached If this is true then prepare_cached is used instead of prepare. Checkout the DBI documentation on this feature before using this feature. saveSQL If this is true then with each query DBIx::Abstract will stuff the generated SQL into the 'lastsql' key in the self payload. This operation is logged at level 5 with the message "Option Change" and the the key, the old value and new new value. query ----- ($sql,@bind_params) ({sql=>$sql,bind_params=>[@bind_params]}) This sends $sql to the database object's query method. This should be used for applications where the existing methods are not able to generate flexible enough SQL for you. If you find yourself using this very often with things other then table manipulation (eg 'create table','alter table','drop table') then please let me know so I can extend DBIx::Abstract to include the functionality you are using. This operation is logged at level 3 run_delayed ----------- Execute delayed update/insert/delete queries. This operation is logged at level 5 with the message "Run delayed". delete ------ ($table[,$where]) ({table=>$table[,where=>$where]}) Deletes records from $table. See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. insert ------ ($table,$fields) ({table=>$table,fields=>$fields}) $table is the name of the table to insert into. $fields is either a reference to a hash of field name/value or a scalar containing the SQL to insert after the "SET" portion of the statement. These all produce functionally equivalent SQL. $db->insert('foo',{bar=>'baz'}); $db->insert('foo',q|bar='baz'|); $db->insert({table=>'foo',fields=>{bar=>'baz'}}); $db->insert({table=>'foo',fields=>q|bar='baz'|}); We also support literals by making the value in the hash an arrayref: $db->insert('foo',{name=>'bar',date=>['substring(now(),1,10)']}); Would generate something like this: INSERT INTO foo (name,date) VALUES (?,substring(now(),1,10)) With "bar" bound to the first parameter. replace ------- ($table,$fields) ({table=>$table,fields=>$fields}) $table is the name of the table to replace into. $fields is either a reference to a hash of field name/value or a scalar containing the SQL to insert after the "SET" portion of the statement. Replace works just like insert, except that if a record with the same primary key already exists then the existing record is replaced, instead of producing an error. update ------ ($table,$fields[,$where]) ({table=>$table,fields=>$fields[,where=>$where]}) $table is the table to update. $fields is a reference to a hash keyed on field name/new value. See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. select ------ select ($fields,[$table,[$where[,$order]]]) ({fields=>$fields,table=>$table[,where=>$where][,order=>$order][,join=>$join][,group=>$group]}) $fields can be either an array reference or a scalar. If it is an array reference then it should be a list of fields to include. If it is a scalar then it should be a literal to be inserted into the generated SQL after "SELECT". $table can be either an array reference or a scalar. If it is an array reference then it should be a list of tables to use. If it is a scalar then it should be a literal to be inserted into the generated SQL after "FROM". See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. $order is the output order. If it is a scalar then it is inserted literally after "ORDER BY". If it is an arrayref then it is join'd with a comma and inserted. $join is there to make joining tables more convenient. It will takes one or more (as an arrayref) sets of statements to use when joining. For instance: $dbh->select({ fields=>'*', table=>'foo,bar', join=>'foo.id=bar.foo_id', where=>{'foo.dollars',['>',30]} }); Would produce: SELECT * FROM foo,bar WHERE (foo.dollars > ?) and (foo.id=foo_id) And put 30 into the bind_params list. $group is/are the field(s) to group by. It may be scalar or an arrayref. If it is a scalar then it should be a literal to be inserted after "GROUP BY". If it is an arrayref then it should be a list of fields to group on. select_one_to_hashref --------------------- ($fields,$table[,$where]) ({fields=>$fields,table=>$table[,where=>$where]}) This returns a hashref to the first record returned by the select. Typically this should be used for cases when your where clause limits you to one record anyway. $fields is can be either a array reference or a scalar. If it is an array reference then it should be a list of fields to include. If it is a scalar then it should be a literal to be inserted into the generated SQL. $table is the table to select from. See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. select_one_to_arrayref ---------------------- ($fields,$table[,$where]) ({fields=>$fields,table=>$table[,where=>$where]}) This returns a arrayref to the first record returned by the select. Typically this should be used for cases when your where clause limits you to one record anyway. $fields is can be either a array reference or a scalar. If it is an array reference then it should be a list of fields to include. If it is a scalar then it should be a literal to be inserted into the generated SQL. $table is the table to select from. See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. select_one_to_array ------------------- ($fields,$table[,$where]) ({fields=>$fields,table=>$table[,where=>$where]}) This returns a array to the first record returned by the select. Typically this should be used for cases when your where clause limits you to one record anyway. $fields is can be either a array reference or a scalar. If it is an array reference then it should be a list of fields to include. If it is a scalar then it should be a literal to be inserted into the generated SQL. $table is the table to select from. See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. select_all_to_hashref --------------------- ($fields,$table[,$where]) ({fields=>$fields,table=>$table[,where=>$where]}) This returns a hashref to all of the results of the select. It is keyed on the first field. If there are only two fields then the value is just the second field. If there are more then two fields then the value is set to an arrayref that contains all of the fields. $fields is can be either a array reference or a scalar. If it is an array reference then it should be a list of fields to include. If it is a scalar then it should be a literal to be inserted into the generated SQL. $table is the table to select from. See also the documentation on `"DBIx::Abstract Where Clauses"' in this node. fetchrow_hashref ---------------- This is just a call to the DBI method. fetchrow_hash ------------- This calls fetchrow_hashref and dereferences it for you. fetchrow_array -------------- This method calls the database handle's method of the same name. fetchall_arrayref ----------------- This method calls the database handle's method of the same name. rows ---- This method calls the database handle's method of the same name. quote ----- This method is passed to the database handle via AUTOLOAD. disconnect ---------- This method is passed to the database handle via AUTOLOAD. commit ------ This method is passed to the database handle via AUTOLOAD. rollback -------- This method is passed to the database handle via AUTOLOAD. trace ----- This method is passed to the database handle via AUTOLOAD. finish ------ This method is passed to the statement handle via AUTOLOAD. bind_col -------- This method is passed to the statement handle via AUTOLOAD. bind_columns ------------ This method is passed to the statement handle via AUTOLOAD. Other things that need explanation ================================== DBIx::Abstract Where Clauses ---------------------------- Where clauses in DBIx::Abstract can either be very simple, or highly complex. They are designed to be easy to use if you are just typing in a hard coded statement or have to build a complex query from data. Wheres are either a scalar, hash-ref or array-ref: If it is a scalar, then it is used as the literal where. If it is a hash-ref then the key is the field to check, the value is either a literal value to compare equality to, or an array-ref to an array of operator and value. { first=>'joe', age=>['>',26], last=>['like',q|b'%|] } Would produce: WHERE first = ? AND last like ? AND age > ? With joe, b'% and 26 passed as bind values. If it is an array-ref then it is an array of hash-refs and connectors: [ { first=>'joe', age=>['>',26] }, 'OR', { last=>['like',q|b'%|] } ] Would produce: WHERE (first = ? AND age > ?) OR (last like ?) With joe, 26 and b'% passed as bind values. [ { first=>'joe', last=>['like','%foo%'], }, 'AND', [ {age=>['>',26]}, 'OR', {age=>['<',30]} ] ] Would produce: WHERE (first = ? AND last like ?) AND ((age > ?) OR (age < ?)) With joe, %foo%, 26 and 30 passed as bind values. SUPPORTED DBD DRIVERS ===================== These drivers have been reported to work: * mysql (development environment) * Pg (with a pre-release version of DBIx::Abstract) * XBase Any driver that uses ODBC syntax should work using the hash ref method. With other drivers you should pass the DBI data source instead (this method will work with all drivers.) CHANGE SINCE LAST RELEASE ========================= * Changed how CVSVERSION and LAST_CHANGE are calculated. * Made it so that you can pass routines literal strings instead of variables (variables are used with bind_params when possbile) by passing a scalar reference. * I also allow array references to do this (in some circumstances) but this is depricated. * Made connect optionally accept DBI handles instead of connection info, by recommendation of Mark Stosberg . AUTHOR ====== Andrew Turner COPYRIGHT ========= (C) Copyright 1998-2000 MINT This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. WEBSITE ======= http://sourceforge.net/projects/dbix-abstract/ SEE ALSO ======== `DBI(3)' in this node