in reply to Re: Database access problem
in thread Database access problem

eval{} is a general solition but is not needed in this case becaue DBI handles have two modes for reporting errors depending on the state of the RaiseError attribute.

If $dbh->{RaiseError} is false (the default) then you can ignore SQL errors simply by not checking to see if there's been one.

Personsally I always open DBI handles with RaiseError true and switch it off locally in blocks where I want to ignore or recover from SQL errors.

To drop an SQL object that may or may not exist I do:

{ local $dbh->{RaiseError} = 0; $dbh->do("drop table DSR_SMR_Result_storage_keep"); }

Obviously if the drop fails for some reason other than the object not existing then I miss the reason but since the next SQL statment is typically about to create the object again I do at least get an error there.

Replies are listed 'Best First'.
Re^3: Database access problem
by bart (Canon) on May 20, 2006 at 12:45 UTC
    There used to be a memory leak when you used local on an element of a tied hash, and a DBI handle is a tied hash. See Memory Leak Bug. I don't know what Perl version it got fixed, if it even got fixed, but in case you're forced to use an old perl version like 5.005_03 or 5.6.0, then it's safer to use eval.

    We're talking about a quick fix for a short piece of code that shouldn't be run too often. In such a case, I'm willing to settle for "easy" and "good enough" code. local is easy, emulating local to avoid the meory leak, isn't.