"Ross J. Reedstrom" wrote:
>
> Hmm, sounds like a vote for nested transactions. The JDBC driver developer
> (Peter Mount) was musing that nested transaction would make large object
> support easier for him, as well.
>
> As to the other example of Oracle not forcing a rollback, I have a feeling
>
"Ross J. Reedstrom" wrote:
>
> Hmm, sounds like a vote for nested transactions. The JDBC driver developer
> (Peter Mount) was musing that nested transaction would make large object
> support easier for him, as well.
>
> As to the other example of Oracle not forcing a rollback, I have a feeling
>
Hmm, sounds like a vote for nested transactions. The JDBC driver developer
(Peter Mount) was musing that nested transaction would make large object
support easier for him, as well.
As to the other example of Oracle not forcing a rollback, I have a feeling
that this may be specific to syntax erro
Peter Eisentraut wrote:
> On 1999-12-08, Lincoln Yeoh mentioned:
>
> > begin;
> > insert into stuff;
> > do some nondatabase things based on last inserted id;
> > update a date in stuff;
> > commit;
> >
> > It seems that if the date is out of the database range, everything is
> > thrown out. Is i
At 01:18 AM 09-12-1999 +0100, Peter Eisentraut wrote:
>Seriously, why do you use a transaction, when you don't want any errors
>caught? Transactions are defined as everything succeeds or nothing goes.
>If you want update to succeed anyhow, put it in it's own transaction
>(i.e., commit before it).
On 1999-12-08, Lincoln Yeoh mentioned:
> begin;
> insert into stuff;
> do some nondatabase things based on last inserted id;
> update a date in stuff;
> commit;
>
> It seems that if the date is out of the database range, everything is
> thrown out. Is it possible to catch the database error and
