Re: JDBC: Fast way to find the number of rows in a ResultSet?



On May 21, 7:46 am, Ronald Fischer <rona...@xxxxxx> wrote:
After a SELECT query via JDBC, is there a fast way to find out the
number of
rows in the result? Of course I could do something like:

Statement s = ...;
ResultSet r = s.executeQuery("select .....");
int rows=0;
r.first();
while(!r.isLast())
{
++rows;
r.next();
}
// The query resulted in 'rows' lines

but this seems to be a bit cumbersome. I also checked the
ResultSet.getMetaData() method, but it seems to provide only the number
of
columns, not the number of rows...

Regards,

Ronald

--
Ronald Fischer <rona...@xxxxxx>
Posted viahttp://www.newsoffice.de/

I wish there was a JDBC FAQ. This would have been the first question.
It's been asked since JDBC and before. Ultimately there is no way to
know. For some DBMSes and for some queries, the DBMS starts sending
the data back to the client before it knows how many rows will
qualify.
You will have to ask the DBMS to send you the number of rows that will
qualify, in a separate query that precedes the real data. Depending on
what applications are doing to the data, you might have to lock all
the
data (not easy or fast in some cases) to ensure that nothing changes
between your 'how-may' query and your send-me-the-data query.
So, the practical solution, if you *must* know, is to buffer the
rows in the client (either in application or an insensitive scrollable
result set or rowset). That will allow the client to know exactly
how many, at the cost of the memory to store it all ahead of time.
That strengthens the best-practices recommendation that you never
read more data to the client than you absolutely need at that moment.
Joe Weinstein at BEA Systems

.



Relevant Pages

  • Re: REST, SOAP, approaches to web connectivity
    ... Novell system after the BP IBM crew had told the client it ... as independent of the interface from the language to the DBMS. ...
    (comp.databases.pick)
  • Re: choices regarding where to place code - in the database or middletier
    ... > from selling that middle tier but I completely disagree. ... server is not a thin client. ... I do believe that no bytes should leave the DBMS ... so it queried the DBMS for a list of the countries in Europe hundreds of times ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middletier
    ... > from selling that middle tier but I completely disagree. ... server is not a thin client. ... I do believe that no bytes should leave the DBMS ... so it queried the DBMS for a list of the countries in Europe hundreds of times ...
    (comp.lang.java.programmer)
  • Re: Size matters to some
    ... specified to the DBMS tools with a maxlen specification, ... database does, without the maxlen specification to the DBMS. ... logical size limitations in the client code. ... something into the framework to prevent that sort of thing from being ...
    (comp.databases.pick)
  • Re: What is the logic of storing XML in a Database?
    ... The receiver of some EDI information is simply a ... a given piece of client software is embedded in that client. ... When it connects with the dbms, it tell the dbms the schema ...
    (comp.databases.theory)