Whoops! Please see below.
Hardy Merrill [EMAIL PROTECTED] 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
^
If you're not using transactions, this should probably
be on(1).
Hardy
> $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.
>
> --
> Hardy Merrill
> Red Hat, Inc.
>
> >
> > thx's
> > --
> > 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:
> > >
> > >>Hi,
> > >>
> > >>we have a small automatied billing system, written in perl
> > >>using DBI to access our MySQL database. This system utilizes
> > >>various control panels for customer, webmasters,...etc...
> > >>where they log in to perform various functions, submit
> > >>forms,..etc.. alot of activity with our MySQL db.
> > >>
> > >>what we'd like to do, is when there is any type of a
> > >>database error, connection, queries,..etc,.. is then
> > >>'trapped' the error for later review, if needed, and display
> > >>in the browser at the time of the error, a simple error
> > >>messages to indicate there was a problem encoutered, nothing
> > >>specific, then log the DBI error on the server for review.
> > >>
> > >>would it be best to log in each error to a file, using
> > >>something like:
> > >>
> > >>if ($DBI::errstr) { $err_mesg = $DBI::errstr };
> > >>
> > >>then write this to a separate error logfile ??
> > >>
> > >>and is it best to set the PrintError=1 & RasieError=1 for
> > >>this type of procedure ??
> > >>
> > >>appreciate any suggestions or tips,
> > >
> > >
> > >Here's my take - I do pretty much exactly what the
> > >DBI perldocs ('perldoc DBI' at a command prompt) suggest
> > >for error handling using 'eval' and Transactions. Here's
> > >a snippet from the DBI perldocs on 'Transactions':
> > >
> > > The recommended way to implement robust transactions in Perl
> > > applica-
> > > tions is to use "RaiseError" and "eval { ... }" (which is very fast,
> > > unlike "eval "...""). For example:
> > >
> > > $dbh->{AutoCommit} = 0; # enable transactions, if possible
> > > $dbh->{RaiseError} = 1;
> > > eval {
> > > foo(...) # do lots of work here
> > > bar(...) # including inserts
> > > baz(...) # and updates
> > > $dbh->commit; # commit the changes if we get this far
> > > };
> > > if ($@) {
> > > warn "Transaction aborted because $@";
> > > $dbh->rollback; # undo the incomplete changes
> > > # add other application on-error-clean-up code here
> > > }
> > >
> > >If any errors occur in the eval, the RaiseError will cause
> > >a die and the $@ variable will be populated with the error
> > >message. So, in the 'if ($@) {' block, you can do whatever
> > >you want to - where it says 'warn...', if you want to display
> > >some generic error message you can do that, and if you want
> > >to log the error you can do that too. I typically log errors
> > >to the webserver(apache) error log by printing errors to
> > >STDERR, which is exactly what 'warn' does above.
> > >
> > >HTH.
