Re: "No results were returned by the query" exception

From: Barry Lind <barry(at)xythos(dot)com>
To: Tim Lewis <tim(dot)lewis(at)hitwise(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: "No results were returned by the query" exception
Date: 2002-03-25 10:06:21
Message-ID: 3C9EF69D.2010203@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Tim,

In postgres an error (any error) causes the transaction to be aborted.
The transaction then must be rolledback in order to continue.

It is clear from your example here that you are rollingback on a
duplicate key error, but I don't know what you are doing for other errors.

thanks,
--Barry

Tim Lewis wrote:
> Dave,
>
> I checked my code against all instances in the driver logs where a
> duplicate key message arose. In all cases, my code has the following
> structure:
>
> try {
> table.insert(tablerec);
> db.commit();
> }
> catch (SQLException e) {
> if (e.getMessage().indexOf("duplicate key") != -1) {
> db.rollback();
> } else {
> throw(e);
> }
> }
>
> So I'm not sure if this is the issue. It may also explain why I have
> not had this problem with the previous driver.
>
> Tim.
>
> Dave Cramer wrote:
>
> Tim,
>
> Here is the good bits from your logs that you sent me.
>
> What they are saying is that you have started a transaction and done an
> insert which failed. After that the transaction needs to be committed,
> or rolled back before anything can be done, even selects.
>
> ERROR: Cannot insert a duplicate key into unique index
> crawlqueue_url_idx
> ERROR: Cannot insert a duplicate key into unique index
> crawlqueue_url_idx
> ERROR: current transaction is aborted, queries ignored until end of
> transaction block
>
> NOTICE: current transaction is aborted, queries ignored until end of
> transaction block
>
> NOTICE: current transaction is aborted, queries ignored until end of
> transaction block
>
> SQLWarning: reason(NOTICE: current transaction is aborted, queries
> ignored until end of transaction block
>
> Dave
>
> > -----Original Message-----
> > From: tlewis(at)kyle(dot)sinewave(dot)com(dot)au
> > [mailto:tlewis(at)kyle(dot)sinewave(dot)com(dot)au] On Behalf Of Tim Lewis
> > Sent: Thursday, March 21, 2002 11:02 PM
> > To: Dave(at)micro-automation(dot)net
> > Cc: 'David Hancock'
> > Subject: Re: [JDBC] "No results were returned by the query"
> exception
> >
> >
> > I'm not clear on what you mean by a transaction is in error?
> >
> > I'm not sure how a select statement returning a resultset
> > with no rows should trigger an exception.
> >
> > Could you explain this in some more detail.
> >
> > Tim.
> >
> > Dave Cramer wrote:
> >
> > > Actually, this only occurs when there is an error in the query. If
> > > there are no results from the query
> > >
> > > Ie select * from foo; returns nothing then you will get an empty
> > > result set
> > >
> > > If on the other hand there is an error in the query like a
> > transaction
> > > is in error, then the exception will be thrown
> > >
> > > Dave
> > >
> > > > -----Original Message-----
> > > > From: pgsql-jdbc-owner(at)postgresql(dot)org
> > > > [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of
> > David Hancock
> > > > Sent: Thursday, March 21, 2002 10:00 PM
> > > > To: pgsql-jdbc(at)postgresql(dot)org
> > > > Subject: [JDBC] "No results were returned by the query"
> exception
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Someone recently pointed out that a SQLException is thrown
> when a
> > > > query returns no results. I have noticed this too. It used to be
> > > > the case (driver version 6.x) that an empty ResultSet was
> > > > returned, and no
> > > > exception thrown.
> > > >
> > > > This new behaviour means that the Postgres driver behaves
> > > > significantly differently to other JDBC drivers, and that code
> > > > written for a generic JDBC connection doesn't work as
> > expected with
> > > > Postgres.
> > > >
> > > > Is this new behaviour a bug or a feature ?
> > > >
> > > > regards,
> > > >
> > > > Dave Hancock.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------(end of
> > > > broadcast)---------------------------
> > > > TIP 4: Don't 'kill -9' the postmaster
> > > >
> > > >
> > >
> > > ---------------------------(end of
> > > broadcast)---------------------------
> > > TIP 1: subscribe and unsubscribe commands go to
> > majordomo(at)postgresql(dot)org
> >
> >
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
> --
> Tim Lewis
> Senior Software Engineer
> Hitwise
> Level 7/580 St Kilda Road
> Melbourne, Victoria 3004
> Phone : +61-3-8530-2400
> Direct: +61-3-8530-2402
> Fax : +61-3-9529-8907
> Mobile: 0414 726 899
> Email : tim(dot)lewis(at)hitwise(dot)com
>
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kovács Péter 2002-03-25 11:45:26 Re: Two Phase commits
Previous Message Dave Cramer 2002-03-25 01:50:01 Re: BigDecimal Bugs