Re:

Karl,

I thought about this, and it presumes that the driver knows that it is
in a transaction. At this point the driver has tried to stay pretty
lightweight assuming the programmer would take care of these things, so
it doesn't even know that it is in a transaction.

I would prefer to see this solved without adding more parsing in the
driver.

Dave

On Tue, 2002-11-05 at 12:35, Karl Goldstein wrote:
> Thanks for clarifying that, Dave. In the absence of useful error codes from the backend, would it
> be possible to simply add an "exceptionThrown" flag in an appropriate place, which gets set when a
> SQLException is thrown in a transaction? Then, if the client code attempts to execute any further
> statements in that transaction, the driver could check the flag and give a clear exception to the
> effect of "Sorry, an exception already occurred in this transaction, you have to rollback before
> you can do anything else reliably with this connection."
>
> Regards,
>
> Karl
>
> --- Dave Cramer <Dave(at)micro-automation(dot)net> wrote:
> > Unfortunately, until the backend gives us usefull error codes, there's
> > not much we can do about catching exceptions intelligently.
> >
> > And yes, the behaviour is intended, once a transaction has failed, you
> > need to end, or roll it back
> >
> > Dave
> > On Tue, 2002-11-05 at 12:19, Karl Goldstein wrote:
> > > I don't have a strong opinion either way. For me, the main problem with the current behavior
> > is
> > > simply that the error message is confusing. If it is indeed the case that any SQLException
> > > invalidates the current transaction (and my impression is that this is not intended), then the
> > > driver should report that directly and not even let you try to execute later statements. The
> > "No
> > > results were returned by the query" error just left me scratching my head.
> > >
> > > Thanks,
> > >
> > > Karl
> > >
> > > --- Daniel Serodio <daniel(at)checkforte(dot)com(dot)br> wrote:
> > > > I've never worked with Oracle, just MySQL and PostgreSQL, but isn't this
> > > > the definition of a transaction?
> > > >
> > > > "A transaction is an atomic unit of processing; it is eigher performed
> > > > in its entirety or not at all"
> > > >
> > > > My understanding of this is that if one statement failed, all of the
> > > > following statements should fail.
> > > >
> > > > On Tue, 2002-11-05 at 14:31, Csaba Nagy wrote:
> > > > > Hi all,
> > > > >
> > > > > I was wondering if there's any chance of this behavior to change in the
> > > > > future ?
> > > > > I mean will it be possible to continue a transaction after one of the SQLs
> > > > > failed, by only rolling back what that query did ?
> > > > > In many real life applications recovery is very possible after a failed
> > > > > query, and (the not failed part of) the transaction should be committed.
> > > > > This is one of the big differences in behavior between Postgres and Oracle,
> > > > > making life hard for porting...
> > > > >
> > > > > Cheers,
> > > > > Csaba.
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > HotJobs - Search new jobs daily now
> > > http://hotjobs.yahoo.com/
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> > --
> > Dave Cramer <Dave(at)micro-automation(dot)net>
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>
> __________________________________________________
> Do you Yahoo!?
> HotJobs - Search new jobs daily now
> http://hotjobs.yahoo.com/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
--
Dave Cramer <davec(at)fastcrypt(dot)com>
Cramer Consulting