> -----Original Message----- > Grant McLean wrote: > > > Nathan Torkington wrote: > > Current recipe list: > > [gnat:~] grep head1 Ora/pcb2/ch21.pod > > =head1 Introduction > > =head1 Authenticating in mod_perl > > =head1 Setting Cookies in mod_perl > > =head1 Accessing Cookie Values from mod_perl > > =head1 Redirecting the Browser from mod_perl > > =head1 Interrogating Headers in mod_perl Handlers > > =head1 Accessing Form Parameters from mod_perl > > =head1 Receiving Uploaded Files in mod_perl > > Database persistence is an important topic but it's hard > to say whether one directive ... > > PerlModule Apache::DBI > > ... constitutes a 'recipe' I agree that database persistence is an important topic and should be included in the perl Cookbook. However, Apache::DBI is not always the answer.
Example: I currently have a need to use database persistence for an Ingres Database. So I installed the DBD::Ingres Module and attempted to use Apache::DBI. Needless to asy it did not work :-( After much searching/posting I got my answer. Henrik Tougaard wrote: (from comp.databases.ingres) I wouldn't bet on Apache::DBi working with DBD::Ingres! Reason: cached statementhandles are not implemented (currently) in DBD::Ingres and Apache::DBI uses them. (It's on my todo list, but not scheduled right now - i seem to have run out of tuits). I assume that the only way of getting permanent connections is to have another process hold them for you - but the hassle of accessing the connections would be so great, that it might be just as easy to avoid CGI entirely and go straight for mod_perl. OK, so now what? This type of situation could be discussed then talk about the Apache::DBI module. Just my 2 cents Ron Hill
