Charles -- 

Good news!  I have seen this problem.  For me, the problem manifested itself
when (a) I accessed Oracle, (b) the jdbc level in my connection-descriptor
was set to 2.0 and (c) the start/end indices were set to values that
incorporated all of the records in the table.   Sounds very similar to your
situation.  The better news is that I've submitted a fix that's already in
cvs.  Get the HEAD revision and try again.

Good luck.

Ron Gallagher
Atlanta, GA
[EMAIL PROTECTED]

-----Original Message-----
From: Charles Brault [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 14, 2003 3:24 PM
To: [EMAIL PROTECTED]
Subject: problem with setStartAtIndex setEndAtIndex


I've upgraded from OJB 9.8 to OJB 9.9.1 with Postgres 7.3 as the database.

I have several user QBE searches that I limit the result set to a 1000 
by doing the following:

Query q = QueryFactory.newQuery(clazz, criteria);
q.setStartAtIndex(startIndex);
q.setEndAtIndex(endIndex);
Collection c = broker.getCollectionByQuery(q);

Some of the queries throw an exception in the database driver, some of 
the queries return correctly.  What's got me perplexed is that one query 
only has a result set with 3 rows in it, another has 820 rows, and they 
both blow up. Other queries have ~100 rows in the result set and they 
work fine.

All the queries will always work if I don't set a start and end index 
value, i.e. comment the lines q.set..., recompile and rerun.

The problem seems to be tied up with getting the size of the result set 
from the result set rather than running a SELECT COUNT(*) query.

I haven't run through all the code with a debugger, but has anyone seen 
a similar problem?


here's a snip of the stack trace from the driver, back to the point the 
query gets executed

java.lang.NullPointerException
     at 
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getRow(AbstractJdbc2ResultSet.ja
va:408)
     at com.p6spy.engine.spy.P6ResultSet.getRow(P6ResultSet.java:127)
     at 
org.apache.ojb.broker.accesslayer.RsIterator.size(RsIterator.java:515)
     at 
org.apache.ojb.broker.accesslayer.ChainingIterator.size(ChainingIterator.jav
a:156)
     at 
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
rsistenceBrokerImpl.java:1276)
     at 
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
rsistenceBrokerImpl.java:1347)
     at 
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
rsistenceBrokerImpl.java:1373)
     at 
org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe
rsistenceBrokerImpl.java:1360)
     at 
org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getCollectionByQu
ery(DelegatingPersistenceBroker.java:273)
     at 
com.topdrawer.ojb.PersistenceServiceImpl.collectionQueryByCriteria(Persisten
ceServiceImpl.java:373)
     at com.topdrawer.user.Model.search(Model.java:131)



-- 
Charles E Brault
[EMAIL PROTECTED]
"Where are we going, and why am I in this handbasket?"


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to