Re: Error-handling Question

From: Rudy Lippan (rlippan_at_remotelinux.com)
Date: 12/16/03


Date: Mon, 15 Dec 2003 20:32:13 -0500 (EST)
To: Hardy Merrill <hmerrill@redhat.com>

On Mon, 15 Dec 2003, Hardy Merrill wrote:

> Paul, you normally don't care about committing or rolling
> back unless you're actually updating the database by doing
> either an INSERT or an UPDATE. When you're just doing
> SELECT and fetches you really don't care about transaction
> processing. If you want to use eval and $@ to trap errors
> with fetches that's fine, but no need to have the rollback
> in the if ($@).

Agreed, but if you have autocommit turned off you should still
commit/rollback or somehow end the transaction at some point. Think about
a long running process that has autocommit turned off & only does selects
but has a transction isolation level of repeatable read or serializable
insead of read commited.

Rudy



Relevant Pages

  • Re: Hot and Cold backups
    ... >>> impression that shutdown immediate was safe, ... >> transaction. ... > 3 - Oracle halts processing of the DML statement and rolls back the ... the application decides when to commit/rollback. ...
    (comp.databases.oracle.server)
  • transactions and stored procedures
    ... execute sp_update_table_001 ... If the connection dies before the commit, will SQL server rollback the ... transaction automatically? ...
    (microsoft.public.sqlserver.programming)
  • Re: update statement
    ... begin transaction ... where testcode ='TOOL' ... --check the data and commit/rollback accordingly. ...
    (microsoft.public.sqlserver.programming)
  • Re: invert tinyint column
    ... try following sequence of update statements: ... begin transaction ... --check the data and issue commit/rollback accordingly. ...
    (microsoft.public.sqlserver.programming)