Hello
Here is the trace (but I think this does not show any additional
information):
DriverManager.initialize: jdbc.drivers = null
JDBC DriverManager initialized
registerDriver:
driver[className=com.sap.dbtech.jdbc.DriverSapDB,[EMAIL PROTECTED]
DriverManager.getConnection("jdbc:sapdb://dbhost/DB")
trying
driver[className=com.sap.dbtech.jdbc.DriverSapDB,[EMAIL PROTECTED]
getConnection returning
driver[className=com.sap.dbtech.jdbc.DriverSapDB,[EMAIL PROTECTED]
---- Thread b166b5 main Timestamp: 2003-10-24 10:46:40.432
==================================
package com.sap.dbtech.jdbc, SAP DB JDBC Driver, SAP AG, 7.4.4 Build
003-000-157-173 on Java 1.4.2
new Connection 'jdbc:sapdb://dbhost/DB'
using [EMAIL PROTECTED] on
Socket[addr=dbhost/192.168.1.1,port=7210,localport=2614]
=> [EMAIL PROTECTED]
[EMAIL PROTECTED] (true)
...
---- Thread 1f01a29 RMI TCP Connection(2)-192.168.1.8 Timestamp:
2003-10-24 10:51:06.485
[EMAIL PROTECTED] (SELECT *
FROM <tab> WHERE <col1>=? AND <col2>=? AND <col3>=?)
...
---- Thread 1f01a29 RMI TCP Connection(2)-192.168.1.8 Timestamp:
2003-10-24 10:51:06.495
=> [EMAIL PROTECTED]
...
[EMAIL PROTECTED] (1, 1)
[EMAIL PROTECTED] (2, 10)
[EMAIL PROTECTED] (3,
700.00)
[EMAIL PROTECTED] ()
=> [EMAIL PROTECTED]
[EMAIL PROTECTED] ()
=> true
[EMAIL PROTECTED] ()
=> true
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> false
[EMAIL PROTECTED] ()
=> 0
Thanks for your comment.
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]
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
