On reflection, I think the right fix for this (apart from fixing
DBD::mysql to support the ParamValues attribute if the latest one
doesn't) is to store the information in a private attribute and
use an overridden FETCH method to return that value.
Tim.
On Wed, Feb 23, 2005 at 09:23:42AM +, Go
It's a DBI bug (or at least mis-feature) that I'll fix for the next
release.
Meanwhile a workaround is to bypass the implicit tie STORE method
and store the attribute directly into the hash. This is probably
the simplest way (untested):
tied(%$sth)->{ParamValues} = \%ParamValues;
Tim.
On Wed
Let me apologize. I did not mean to send an attachment to the list.
Originally I attached my pm and then decided that I shouldn't do that.
I then pasted it into the body of the email but forgot to unattach the
file before sending.
Sorry
>>>Ian Harisay <[EMAIL PROTECTED]> 11/18 9:55 am >>
I don't know if it would be the right approach for you, but you can catch the WARN and manipulate it. I did this with my module CommandOpt.pm. It extends Getopt::Long. I test for a particular WARN being thrown.
--- begin module ---
### be
On Wed, Nov 17, 2004 at 06:46:49PM -0800, Viner, David wrote:
> Hi,
>
> I am attempting to write a simple subclass of DBI which will handle some
> auto-reconnect behavior. In this case, I am connecting to a MySQL server,
> and I can properly reconnect. However, if the user sets 'PrintError' to
>
Posted too quickly. As soon as I sent this I realized I hadn't checked the DBI docs.
My apologies,
--TWH
-Original Message-
From: Tim Howell
Sent: Tuesday, February 17, 2004 12:36 PM
To: [EMAIL PROTECTED]
Subject: Subclassing DBI...
I'd like to add a method to my statement handles so
