in reply to Tricks with DBI
A great article, but this line could potentially be misleading.
The Apache::DBI module is completely transparent; so you don't need to touch your scripts for any reason. Where Apache::DBI actually is defined, is in Apache's configuration file (httpd.conf by default).
Sample mod_perl section of httpd.conf
... # preload these modules PerlModule Apache::Registry; PerlModule CGI; PerlModule Apache::DBI; PerlModule DBI; # startup script PerlRequire /path/to/startup.pl ...
If you have a lot of modules to preload, or to use Perl syntax as illustrated above by bttrot, you can define them in the startup script instead. The rule about Apache::DBI going before any other DBI modules still applies.
Just thought I'd clear that up for anyone who read it to mean, "Add use Apache::DBI; to your CGI scripts."
Apache::DBI Potential Traps (UPDATE)
Before everyone runs and starts using Apache::DBI, I'd like to add a cautionary warning.
Don't create a database connection in startup.pl. When Apache forks the connection will be clobbered. Instead Apache::DBI has the startup.pl safe Apache::DBI->connect_on_init() method (that runs in the PerChildInit phase), though there are caveats to it as well.
Don't use this module if you're logging users into the database individually. For each apache child (pre-forking model) a database connection may be established for each connection string used. This means if you have 10 apache children connecting as 'wwwuser', you'll possibly have 10 connections being kept open. If you log each of say qw(Bill Joe Sally Evan Sue) in individually, a connection for each user in each child might be established. That's 50 open database connections in our tiny example.
More detailed info on these and other issues have been gathered in the new mod_perl and Relational Databases article, be sure to check it out.