Thanks! It seems to be working correctly after implementing your changes.
Brian
Perrin Harkins wrote:
I plan to submit a patch for Ima::DBI to fix this, but in the meantime I
am handling it by overriding db_Main and doing the connections myself.
Here's the code I use:
my $db_options = {
Raise
Heyho,
I spent ages trying to track down a mysql/Apache::DBI
bug, and whilst I'm not sure what's going wrong with
your system, I found it useful to add the PID of the
individual mysql process (not sure if you can do this
with postgresql) to the $dbh and then implement a
error handler which logs th
On Tue, 2004-10-26 at 15:52, Brian Dimeler wrote:
> The connection code is actually in a Class::DBI
> module, which gets use()'d by all of my scripts.
Bingo, that's the problem. Class::DBI uses Ima::DBI, which does not
play well with Apache::DBI. It keeps its own connection cache in
closures an
Thanks for the suggestion, but it's the same connection with the same
params every time. The connection code is actually in a Class::DBI
module, which gets use()'d by all of my scripts. This module isn't in my
startup script, so that each process keeps its own copy. So there are
multiple handle
Brian Dimeler wrote:
So anyway, I recompiled mod_perl to ensure these kinds of handlers
were enabled, restarted the server with $Apache::DBI::DEBUG set to 2,
and sure enough, I started getting debug messages about rollbacks
after each script finished executing. Problem is.. they stopped, after
Hi,
I've been converting some old CGI scripts for use with mod_perl and
Apache::DBI. These scripts access a Postgres database through DBI. I
didn't have any trouble until I began writing a new script which in the
development phase has generated a few bad SQL commands (my fault, not
the problem
