I'm using JDBC 2.0 for connecting to Access Database (mdb). I've the
following problems: some of new methods relatives to ResultSet don't
work well. For example if I try to invoke the previous method I get an
exception (Operation Not Supported). Maybe the odbc bridge driver
presents in JDBC 2.0 still works like the that one in JDBC 1.1 so the
new methods are not implemented. Did anybody have the same problems?
++bye
--------
To send me email remove "REMOVETHIS" from my address.
I have searched the JDBC API and I cannot find a reference to how
to retireve the # of rows returned in a ResultSet.
I would like to avoid storing what I read from the ResultSet into
a Vector and then processing the Vectors elements to put them into
arrays.
Is there any method that can be invoked to return the # of rows ?
Thank you,
-John K
Sent via Deja.com http://www.deja.com/
Before you buy.
Most databases don't return the number of rows in a result set
until after all the row data has been sent. This being the case,
JDBC really can't provide you with the number of rows in the result
set.
--
=======================================================================
Life is short. | Craig Spannring
Bike hard, ski fast. | c...@internetcds.com
--------------------------------+------------------------------------
Use:
resultset.last(); // Moves the cursor to the last row in the result
set.
int total_numb_of_rows_in_resultset= resultset.int getRow() //
Retrieves the current row number.
resultset.first(); // Moves the cursor to the first row in the
result set.
All this are JDBC 2.0 method....
You probably want to use beforeFirst() instead of first(), if you
want to be back where you started.
Also, that is one of the worst variable names I have ever seen.
;-)
John L
JDBC 2.0 Returns the fetch size for this result set.
Returns:
the current fetch size for this result set
Throws:
SQLException - if a database access error occurs
Bye Andree
John K wrote:
>
> Hi all,
>
> I have searched the JDBC API and I cannot find a reference to how
> to retireve the # of rows returned in a ResultSet.
>
This is a lovely description of a function that has nothing
whatsoever to do with the number of rows in the result set.
Several correct answers have been posted in numerous threads here
on a weekly basis. The three solutions are using SELECT COUNT(*)
..., the JDBC 2.0 ResultSet methods last, getRow, and
beforeFirst, and some driver-specific method for databases that
support such an operation.
John L
cc: Andree Große
> Andree Große wrote:
> > public int getFetchSize()
> > throws SQLException
> > JDBC 2.0 Returns the fetch size for this result set.
> > Returns:
> > the current fetch size for this result set
> > Throws:
> > SQLException - if a database access error occurs
>
> This is a lovely description of a function that has nothing
> whatsoever to do with the number of rows in the result set.
You are correct, sir. Further, here is some text I posted in '97
on the topic:
"There will never be a row-count command easier/faster
than select count(*). Furthermore, the count(*) will not be
fast, and will be very slow in some instances, and may
not even be accurate anyway!
Please note that we are communicating with an RDBMS.
The number of rows to be returned for a query depend
intimately on the qualifiers, sorting requirements,
the level of transactional control and the other users
of the DBMS. Many queries require the DBMS to generate
the entire result set in a temporary space before it
can be known how many rows there will be. Depending on
the query, DBMS, and transactional isolation level, the
DBMS may throw all that data away, and have to do it all
again when you send the query to actually retrieve the data.
Lastly, depending on how busy your database is, the number
or rows you get whan you make your query may be different
than what you were told from select count(*).
The best defense is to build as much intelligence into the
DDL and SQL as possible, to limit the data returned to that
which you actually want. Then build the app. to handle
whatever it may get."
Joe Weinstein, BEA WebLogic
>
>
> Several correct answers have been posted in numerous threads here
> on a weekly basis. The three solutions are using SELECT COUNT(*)
> ..., the JDBC 2.0 ResultSet methods last, getRow, and
> beforeFirst, and some driver-specific method for databases that
> support such an operation.
>
> John L
>
> cc: Andree Große
--
PS: Hey folks, we're hiring Java engineers for our WebLogic
Engineering group in downtown S.F. Send me your resume.
--------------------------------------------------------------------------------
The Weblogic Application Server from BEA
JavaWorld Editor's Choice Award: Best Web Application Server
Java Developer's Journal Editor's Choice Award: Best Web Application Server
Crossroads A-List Award: Rapid Application Development Tools for Java
Intelligent Enterprise RealWare: Best Application Using a Component Architecture
http://weblogic.beasys.com/press/awards/index.htm
Regards, Andree
John Lacey wrote:
>
> Andree Große wrote:
> >
> > public int getFetchSize()
> > throws SQLException
> >
> > JDBC 2.0 Returns the fetch size for this result set.
> > Returns:
> > the current fetch size for this result set
> > Throws:
> > SQLException - if a database access error occurs
>
> This is a lovely description of a function that has nothing
> whatsoever to do with the number of rows in the result set.
>
Andree Große wrote:
> Oh that's great a description without content!
> The new way of SUN ? So it's a useless method.
> If i have to do 2 select-statements to count
> the number of rows of a result set then i miss
> a very simple method to get it from MetaData
> of ResultSet for example. That's bull shit.
FetchSize has to do with how many rows come over at a time
for caching at the client. This is so every call to next() doesn't
require client-DBMS communication. The reason it's configurable
is so the client can avoid memory trouble with huge result sets.
As I posted before, many times, there is no way for a DBMS to
know ahead of time how many rows will be returned from a query.
Even select count(*) beforehand won't be a guarantee. Even if
the JDBC spec folks added a method whose charter was to tell
you how many rows were coming back in a result set, none of
the DBMS protocols I'm aware of, send that information. This
means the driver would have to internally fetch all rows and buffer
them up in client address space in order to answer your question.
This would be slow and memory-intensive. Not so much bullshit,
it's just that life isn't easy sometimes...
Joe
>
>
> Regards, Andree
>
> John Lacey wrote:
> >
> > Andree Große wrote:
> > >
> > > public int getFetchSize()
> > > throws SQLException
> > >
> > > JDBC 2.0 Returns the fetch size for this result set.
> > > Returns:
> > > the current fetch size for this result set
> > > Throws:
> > > SQLException - if a database access error occurs
> >
> > This is a lovely description of a function that has nothing
> > whatsoever to do with the number of rows in the result set.
> >
> > Several correct answers have been posted in numerous threads here
> > on a weekly basis. The three solutions are using SELECT COUNT(*)
> > ..., the JDBC 2.0 ResultSet methods last, getRow, and
> > beforeFirst, and some driver-specific method for databases that
> > support such an operation.
> >
> > John L
> >
> > cc: Andree Große
--