Hello That's exactly the problem: when I wanted to reproduce the wrong behaviour, everything worked correct (in a simple testclass) although the same query was called. But the failure always happens at the same place within our persistence-framework, thus the behaviour is deterministic. And it has nothing to do with concurrency, this cause can be excluded.
By the way ... > > rs.last(): false // is NOT incorrect*** > > rs.getRow(): 0 // HERE IS THE PROBLEM *** this comment is not correct: since the resultset contains many rows that method should return true, I think ([EMAIL PROTECTED] <code>true</code> if the cursor is on a valid row; <code>false</code> if there are no rows in the result set...). I hope a JdbcTrace can clarify that. Thanks, Gabriel Matter "Paskamp, Marco" schrieb: > > Hello! > Do you have a repeatable test case I could use? Maybe you can also send me a > jdbc-trace (http://sapdb.2scale.net/moin.cgi/JdbcTrace) to understand how your > application uses the jdbc driver. > > Thanks, > Marco > ---------------------------------------------- > Marco PASKAMP > SAP DB, SAP Labs Berlin > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Freitag, 24. Oktober 2003 01:48 > > To: Schroeder, Alexander; [EMAIL PROTECTED] > > Subject: [JDBC] Bug in last()/getRow() ? > > > > > > Hello > > > > I use todays JDBC-Driver (Implementation-Version: 7.4.4, Build > > 003-000-157-173) and found a bug (I think it is one) when trying to > > detect the number of rows by calling the two methods > > > > boolean last = rs.last(); > > count = rs.getRow(); > > > > last: false (this is not incorrect), but > > count: should be >500 in my case, but is 0. > > > > While this usually works perfect, it does not for the exactly same > > sql-query/statement. It seems to depend on a state but I have > > no idea on > > which one. To be sure that the resultset really contains all the rows > > (several hundreds) I first called rs.next() three times and > > checked the > > resultset (rs.getString(1) returnd the correct values for the first > > three rows for example). > > > > While it is correct that last() returns false, rs.getRow() > > should return > > a number > 500 in my case (this usually happens but in rare > > cases not). > > > > Here are some other values returned by the ResultSet-Object used: > > > > rs.isBeforeFirst(): false > > rs.isFirst(): false > > rs.getRow(): 3 // we are on the third row (of many rows), that's > > correct. > > rs.last(): false // is NOT incorrect > > rs.getType(): 1005 //default > > rs.getRow(): 0 // HERE IS THE PROBLEM > > rs.last(): false // repeated call returns the same values. > > rs.getRow(): 0 // HERE IS THE PROBLEM > > > > > > I guess it was best to add some debugging code into > > ResultSetSapDB.java > > to find out which of all the cases that are considered within the > > implementation of the methods last() and getRow() causes that > > behaviour. > > If necessary, we'll do that. > > > > Thanks for any comment. > > > > G. Matter > > Invoca Systems > > > > "Schroeder, Alexander" schrieb: > > > > > > Hi, > > > > > > > Hi, > > > > > > > > how can i get the number of rows returned by > > > > PreparedStatement s = "..."; > > > > ResultSet r = s.executeQuery(); > > > > > > > > I currently use > > > > int count; > > > > if (r.isAfterLast()) > > > > count = 0; > > > > > > This is wrong, as JDBC says for isAfterLast: > > > > > > Returns true if the cursor is after the last row; false > > > if the cursor is at any other position or the result set contains > > > no rows. > > > > > > Also, if there are no rows, getRow() returns 0 immediately, > > and calling 'last' does > > > not harm. > > > > > > > else > > > > { > > > > r.last(); > > > > count = r.getRow(); > > > > } > > > > > > > > My hope is, that last() instructs the kernel to move the > > > > cursor to the > > > > last row, and therefor the traffic won't be that much. > > > > > > Yes, but *only* this. Actually calling 'getRow' while being > > > on the 'last' row uses some tricks, which may or may not > > > be performant enough. Its performance depends heavily on > > > the particular strategy chosen by the database to create > > > the result, and what you have done on the result before. > > > (Fetching through the result, and afterwards using that > > > sequence above is quite more performant as doing it as > > > first operation). > > > > > > > Is there a more sapdb-optimized version to get the number of rows > > > > returned by a select-statement? > > > > > > No. If you look at other DBMS', you will see that getRow() is > > > always relatively expensive. > > > > > > If you want only the number, there is no need for selecting the > > > data => use a "SELECT COUNT(...) ...", > > > if you need to handle the data you have to live with the fact that > > > DBMS usually only know the result count when they have built up > > > the result completely. > > > > > > Regards > > > Alexander Schröder > > > SAP Labs Berlin > > > _______________________________________________ > > > sapdb.general mailing list > > > [EMAIL PROTECTED] > > > http://listserv.sap.com/mailman/listinfo/sapdb.general > > > > -- > > MaxDB Discussion Mailing List > > For list archives: http://lists.mysql.com/maxdb > > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
