Re: Toggling dbi attribute within a connection?

JupiterCrash,
You are breaking encapsulation. If DBI doesn't provide an mutator method for setting the RaiseError flag then you should expect weird behavior by mucking with the internals. With that said, you might want to try:

delete $dbh->{RaiseError};
[download]

Update (30 seconds later) After reading more of TFM, it seems that you are encouraged to muck with internals. I find this odd, but after recently porting Config::Tiny from p5 to p6 it isn't the first time I have seen it. DBI gives the example of limiting the scope as follows:

{
    local $h->{RaiseError};  # localize and turn off for this block
}
[download]

If you can't limit the scope and need to turn it off/on at will, I suggest using delete which was my first guess anyway.

Cheers - L~R

Comment on Re: Toggling dbi attribute within a connection? Select or Download Code

Replies are listed 'Best First'.
Re^2: Toggling dbi attribute within a connection? by perrin (Chancellor) on May 12, 2005 at 15:30 UTC
Those aren't the internals. It's just a really nasty interface that presents these method calls as hash values using typeglob magic.	[reply]
Re^3: Toggling dbi attribute within a connection? by Limbic~Region (Chancellor) on May 12, 2005 at 15:32 UTC
perrin, I see. jZed is giving me an education on this in the chatterbox. Thanks. Cheers - L~R	[reply]
Re^3: Toggling dbi attribute within a connection? by adrianh (Chancellor) on May 13, 2005 at 11:24 UTC
It's just a really nasty interface that presents these method calls as hash values using typeglob magic. While it is ugly, it does have it does have the advantage of allowing you to easily localise a setting for a block using `local`.	[reply] [d/l]
Re^2: Toggling dbi attribute within a connection? by JupiterCrash (Monk) on May 12, 2005 at 15:28 UTC
First, thank you very much for the suggestions. I had thought that delete $dbh->{RaiseError} might work, too, but it gives this error: Can't locate object method "DELETE" via package "DBI::db" I had tried (and just tried again) making it local in scope when setting it, as you suggested, and that does not seem to be working either to turn it on only temporarily. (it stays on outside of the scrope) This is weird. Matt	[reply]
Re^3: Toggling dbi attribute within a connection? by Limbic~Region (Chancellor) on May 12, 2005 at 15:35 UTC
Matt, First, DELETE is not delete. Second, can you provide a minimal example of the code that you can't get to work per the docs (using naked blocks for scopes). Cheers - L~R	[reply]
Re^4: Toggling dbi attribute within a connection? by ikegami (Patriarch) on May 12, 2005 at 16:29 UTC
%$dbh is tied, so the delete translates to a DELETE.	[reply]
Re^4: Toggling dbi attribute within a connection? by JupiterCrash (Monk) on May 12, 2005 at 15:46 UTC
The error complains about 'DELETE', yes, but I am calling 'delete'. `delete $dbh->{RaiseError};` [download] Minimal example of code as follows: `# at this point RaiseError is off as per default connection { local $dbh->{RaiseError} = 1; LABEL_START_TRANSACTION1: eval { # prepare the sql statement $sth = $dbh->prepare($sql); # execute the sql statement $sth->execute(); }; } if ($@) { .. handle the error }` [download] But at this point, right below where this code ends, dbi calls still act as if I have RaiseError turned on. Matt	[reply] [d/l] [select]