-- Mike<mickalo>Blezien =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Thunder Rain Internet Publishing Providing Internet Solutions that work! http://www.thunder-rain.com Quality Web Hosting http://www.justlightening.net MSN: [EMAIL PROTECTED] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Hardy Merrill wrote:
Mike Blezien [EMAIL PROTECTED] wrote:
Hardy,
thx's I think this maybe exactly what we were looking for, but currently do not utilize transactions in our coding. Is there another preferred way to do about the same thing without using transactions ??
Mike, you can still use the same logic, even if you don't utilize transactions - your code might look like this:
$dbh->{AutoCommit} = 0; # enable transactions, if possible $dbh->{RaiseError} = 1; eval { foo(...) # do lots of work here bar(...) # including inserts baz(...) # and updates }; if ($@) { warn "Problem with foo, bar, or baz: $@"; # add other application on-error-clean-up code here }
Another thing you can do which I have done before is to do your own dies in an eval - that will cause the $@ variable to be populated with the error message. So you could do something like this:
eval { my $sth = $dbh->prepare(qq{ UPDATE foo SET name = ?, phone = ? WHERE id = ? }) || die "Prepare failed: $DBI::errstr"; $sth->execute($name, $phone, $id) || die "Execute failed: $DBI::errstr"; }; if ($@) { warn "Problem with UPDATE: $@"; # add other application on-error-clean-up code here }
But this is more work, and really yields about the same thing anyway - my preference is to use the first method (with RaiseError=1). Read the perldocs on RaiseError.
HTH.
