You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mike Ahlers <mi...@hippo.nl> on 2004/04/07 11:44:36 UTC
Problem with OJB
Hi,
I am a new kid on the block and work with the OJB/JDO block. Using a
database with no relations works perfectly, however when I increase
complexity and use foreign keys I fail to get it working. The following
error is what I get:
[org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while
iterate Result Set for query
org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from class
nl.hippo.nvpt.Articles where [id = 55], class descriptor: nl.hippo.nvpt.Ar
ticles]
/ by zero java.lang.ArithmeticException: / by zero
Can anybody explain why iterating over a result-set gives a div by zero?
Thanks in advance,
Mike Ahlers
Re: Problem with OJB
Posted by Mike Ahlers <mi...@hippo.nl>.
I am using rc6. I can see using Integer is better, unfortunately that
didn't solve the problem (neither did removing the "default-fetch").
- Mike
Brian McCallister wrote:
> Which version of OJB are you using? Line numbers don't match up to
> the one I have, which is, admittedly, cvs head -- though rc6 and cvs
> head are pretty similar right now.
>
> Okay, some try-the-common-things-first:
>
> Try changing the PK and FK values to Integer types instead of int.
> Using the primitives can really boggle OJB as it is not safe to
> presume 0 is equivalent to not-set (null).
>
> Test.
>
> Remove the "default-fetch" as it only applies to JDO rinse, repeat.
>
> Will look at more carefully asap =)
>
> -Brian
>
> On Apr 7, 2004, at 9:56 AM, Mike Ahlers wrote:
>
>> Hi Brian,
>>
>> I can try... let me describe what I got so far. After digging
>> deeper into this and producing some relevant debug statements I find
>> the following written on my console:
>>
>> console output:
>> --- start snippet ---
>> NVTPDataAccessObject2: getArticle: called with id: 56
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery : Query from class nl.hippo.nvpt.Articles where [id = 56]
>> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
>> DEBUG: SQL:SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0
>> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT
>> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE
>> A0.ID = ?
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery: com.mysql.jdbc.PreparedStatement@13c33b7: SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
>> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.
>> ID FROM ARTICLES A0 WHERE A0.ID = 56
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
>> RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query:
>> Query from class nl.hippo.nvpt.Articles where [id = 56], class
>> descriptor: nl.hippo.nvpt.Articles]] initialized
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
>> DEBUG: SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery : Query from class nl.hippo.nvpt.Articles where [type = 3]
>>
>>
>> ^^^^^^
>>
>> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
>> DEBUG: SQL:SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0
>> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT
>> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE
>> A0.TYPE = ?
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery: com.mysql.jdbc.PreparedStatement@1f8f8c8: SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
>> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.
>> ID FROM ARTICLES A0 WHERE A0.TYPE = 3
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
>> RsIterator[org.apache.ojb.
>> broker.accesslayer.RsQueryObject[query: Query from class
>> nl.hippo.nvpt.Articles where [type = 3], class descriptor:
>> nl.hippo.nvpt.Articles]] initialized
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> ...
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() ->
>> false
>> java.lang.ArithmeticException: / by zero
>> at
>> org.apache.ojb.broker.accesslayer.BasePrefetcher.<init>(BasePrefetcher.
>> java:115)
>> at
>> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.<init>(Rel
>> ationshipPrefetcherImpl.java:78)
>> at
>> org.apache.ojb.broker.accesslayer.CollectionPrefetcher.<init>(Collectio
>> nPrefetcher.java:97)
>> at
>> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createR
>> elationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Q
>> ueryReferenceBroker.java:315)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
>> eryReferenceBroker.java:185)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
>> eryReferenceBroker.java:242)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
>> eryReferenceBroker.java:262)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(Quer
>> yReferenceBroker.java:513)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(Que
>> ryReferenceBroker.java:695)
>> at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(Persistenc
>> eBrokerImpl.java:1153)
>> at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(
>> PersistenceBrokerImpl.java:1217)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getReferencedObject(Que
>> ryReferenceBroker.java:478)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReference(Query
>> ReferenceBroker.java:358)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReferences(Quer
>> yReferenceBroker.java:400)
>> at
>> org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsI
>> terator.java:501)
>> at
>> org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293)
>> at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Persi
>> stenceBrokerImpl.java:1298)
>> at
>> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery
>> (DelegatingPersistenceBroker.java:291)
>> at
>> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery
>> (DelegatingPersistenceBroker.java:291)
>> at nl.hippo.nvpt.NVTPDataAccessObject2.getArticle(Unknown
>> Source)
>> --- end snippet ---
>>
>> Note the sudden 'translation' of 'Article_types' into 'Articles'. I
>> am expecting a query like: Query from class
>> nl.hippo.nvpt.Article_types where [type = 3] and not Query from
>> class nl.hippo.nvpt.Articles where [type = 3]. Could this a bug in
>> the SqlGeneratorDefaultImpl regarding nested queries? Anyways, this
>> is what I am trying to map:
>>
>> repository.xml:
>> --- start snippet ---
>> <class-descriptor class="nl.hippo.nvpt.Articles" table="ARTICLES">
>> <field-descriptor name="id" primarykey="true"
>> default-fetch="true" column="ID" jdbc-type="INTEGER"/>
>> <field-descriptor name="type" default-fetch="true" column="TYPE"
>> jdbc-type="INTEGER"/>
>> ....
>> <reference-descriptor name="article_types"
>> class-ref="nl.hippo.nvpt.Article_types" auto-update="false"
>> auto-delete="false">
>> <foreignkey field-ref="type"/>
>> </reference-descriptor>
>> </class-descriptor>
>> --- end snippet ---
>>
>> The following classes are generated (like the repository.xml) by
>> Druid and has setters and getters.
>>
>> Articles.java:
>> --- start snippet ---
>> public class Articles {
>> public int id;
>> public int type;
>> public Article_types article_types;
>> ...
>> }
>> --- end snippet ---
>>
>> Article_types:
>> --- start snippet ---
>> public class Article_types
>> {
>> public int id;
>> public String naam;
>> public String omschrijving;
>> }
>> --- end snippet ---
>>
>> My data access object looks like this:
>> --- start snippet ---
>> public Articles getArticle(int id) {
>> ...
>> System.out.println("NVTPDataAccessObject2: getArticle: called with
>> id: " + id);
>> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
>> // Create criteria
>> criteria = new Criteria();
>> criteria.addEqualTo("id", new Integer(id)); // Refine
>> criteria
>> // Create query
>> query = new QueryByCriteria(Articles.class, criteria);
>> result = (Articles) broker.getObjectByQuery(query);
>> ...
>> return result;
>> --- end snippet ---
>>
>> Brian McCallister wrote:
>>
>>> Any chance you can post the relevent repository_user.xml snippets
>>> and an outline at least of what they map to? More than happy to
>>> help you work out what's going on =)
>>>
>>> I have never seen divide by zero errors from OJB =(
>>>
>>> Also, do you get the same problem if you try the query via the
>>> PersistenceBroker api instead of the JDO api?
>>>
>>> -Brian
>>>
>>> On Apr 7, 2004, at 5:44 AM, Mike Ahlers wrote:
>>>
>>>> Hi,
>>>>
>>>> I am a new kid on the block and work with the OJB/JDO block. Using
>>>> a database with no relations works perfectly, however when I
>>>> increase complexity and use foreign keys I fail to get it working.
>>>> The following error is what I get:
>>>>
>>>> [org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while
>>>> iterate Result Set for query
>>>> org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from
>>>> class nl.hippo.nvpt.Articles where [id = 55], class descriptor:
>>>> nl.hippo.nvpt.Ar
>>>> ticles]
>>>> / by zero java.lang.ArithmeticException: / by zero
>>>>
>>>> Can anybody explain why iterating over a result-set gives a div by
>>>> zero?
>>>>
>>>> Thanks in advance,
>>>> Mike Ahlers
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Problem with OJB
Posted by Mike Ahlers <mi...@hippo.nl>.
Hi Brian,
I've found the 'source' of the problem. In short it is about
instantiating a collection of inverse foreign-keys, i.e. references to
objects. When I change my repository.xml and omit the collection
descriptors it works! (yay). Otherwise this is what is happening: get
Article -> get Article-Type -> create collection of inverse foreign keys
-> (does intermediate query, fetching all articles with same
article-type), at end of iterating this collection it goes bewm.
Hopefully this is of any help in order to tackle the / by zero error.
Let me know if you need more information.
Regards,
Mike Ahlers
Brian McCallister wrote:
> Which version of OJB are you using? Line numbers don't match up to
> the one I have, which is, admittedly, cvs head -- though rc6 and cvs
> head are pretty similar right now.
>
> Okay, some try-the-common-things-first:
>
> Try changing the PK and FK values to Integer types instead of int.
> Using the primitives can really boggle OJB as it is not safe to
> presume 0 is equivalent to not-set (null).
>
> Test.
>
> Remove the "default-fetch" as it only applies to JDO rinse, repeat.
>
> Will look at more carefully asap =)
>
> -Brian
>
> On Apr 7, 2004, at 9:56 AM, Mike Ahlers wrote:
>
>> Hi Brian,
>>
>> I can try... let me describe what I got so far. After digging
>> deeper into this and producing some relevant debug statements I find
>> the following written on my console:
>>
>> console output:
>> --- start snippet ---
>> NVTPDataAccessObject2: getArticle: called with id: 56
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery : Query from class nl.hippo.nvpt.Articles where [id = 56]
>> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
>> DEBUG: SQL:SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0
>> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT
>> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE
>> A0.ID = ?
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery: com.mysql.jdbc.PreparedStatement@13c33b7: SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
>> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.
>> ID FROM ARTICLES A0 WHERE A0.ID = 56
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
>> RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query:
>> Query from class nl.hippo.nvpt.Articles where [id = 56], class
>> descriptor: nl.hippo.nvpt.Articles]] initialized
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
>> DEBUG: SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery : Query from class nl.hippo.nvpt.Articles where [type = 3]
>>
>>
>> ^^^^^^
>>
>> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
>> DEBUG: SQL:SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0
>> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT
>> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE
>> A0.TYPE = ?
>> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
>> executeQuery: com.mysql.jdbc.PreparedStatement@1f8f8c8: SELECT
>> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
>> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
>> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.
>> ID FROM ARTICLES A0 WHERE A0.TYPE = 3
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
>> RsIterator[org.apache.ojb.
>> broker.accesslayer.RsQueryObject[query: Query from class
>> nl.hippo.nvpt.Articles where [type = 3], class descriptor:
>> nl.hippo.nvpt.Articles]] initialized
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> ...
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
>> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() ->
>> false
>> java.lang.ArithmeticException: / by zero
>> at
>> org.apache.ojb.broker.accesslayer.BasePrefetcher.<init>(BasePrefetcher.
>> java:115)
>> at
>> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.<init>(Rel
>> ationshipPrefetcherImpl.java:78)
>> at
>> org.apache.ojb.broker.accesslayer.CollectionPrefetcher.<init>(Collectio
>> nPrefetcher.java:97)
>> at
>> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createR
>> elationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Q
>> ueryReferenceBroker.java:315)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
>> eryReferenceBroker.java:185)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
>> eryReferenceBroker.java:242)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
>> eryReferenceBroker.java:262)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(Quer
>> yReferenceBroker.java:513)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(Que
>> ryReferenceBroker.java:695)
>> at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(Persistenc
>> eBrokerImpl.java:1153)
>> at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(
>> PersistenceBrokerImpl.java:1217)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.getReferencedObject(Que
>> ryReferenceBroker.java:478)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReference(Query
>> ReferenceBroker.java:358)
>> at
>> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReferences(Quer
>> yReferenceBroker.java:400)
>> at
>> org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsI
>> terator.java:501)
>> at
>> org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293)
>> at
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Persi
>> stenceBrokerImpl.java:1298)
>> at
>> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery
>> (DelegatingPersistenceBroker.java:291)
>> at
>> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery
>> (DelegatingPersistenceBroker.java:291)
>> at nl.hippo.nvpt.NVTPDataAccessObject2.getArticle(Unknown
>> Source)
>> --- end snippet ---
>>
>> Note the sudden 'translation' of 'Article_types' into 'Articles'. I
>> am expecting a query like: Query from class
>> nl.hippo.nvpt.Article_types where [type = 3] and not Query from
>> class nl.hippo.nvpt.Articles where [type = 3]. Could this a bug in
>> the SqlGeneratorDefaultImpl regarding nested queries? Anyways, this
>> is what I am trying to map:
>>
>> repository.xml:
>> --- start snippet ---
>> <class-descriptor class="nl.hippo.nvpt.Articles" table="ARTICLES">
>> <field-descriptor name="id" primarykey="true"
>> default-fetch="true" column="ID" jdbc-type="INTEGER"/>
>> <field-descriptor name="type" default-fetch="true" column="TYPE"
>> jdbc-type="INTEGER"/>
>> ....
>> <reference-descriptor name="article_types"
>> class-ref="nl.hippo.nvpt.Article_types" auto-update="false"
>> auto-delete="false">
>> <foreignkey field-ref="type"/>
>> </reference-descriptor>
>> </class-descriptor>
>> --- end snippet ---
>>
>> The following classes are generated (like the repository.xml) by
>> Druid and has setters and getters.
>>
>> Articles.java:
>> --- start snippet ---
>> public class Articles {
>> public int id;
>> public int type;
>> public Article_types article_types;
>> ...
>> }
>> --- end snippet ---
>>
>> Article_types:
>> --- start snippet ---
>> public class Article_types
>> {
>> public int id;
>> public String naam;
>> public String omschrijving;
>> }
>> --- end snippet ---
>>
>> My data access object looks like this:
>> --- start snippet ---
>> public Articles getArticle(int id) {
>> ...
>> System.out.println("NVTPDataAccessObject2: getArticle: called with
>> id: " + id);
>> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
>> // Create criteria
>> criteria = new Criteria();
>> criteria.addEqualTo("id", new Integer(id)); // Refine
>> criteria
>> // Create query
>> query = new QueryByCriteria(Articles.class, criteria);
>> result = (Articles) broker.getObjectByQuery(query);
>> ...
>> return result;
>> --- end snippet ---
>>
>> Brian McCallister wrote:
>>
>>> Any chance you can post the relevent repository_user.xml snippets
>>> and an outline at least of what they map to? More than happy to
>>> help you work out what's going on =)
>>>
>>> I have never seen divide by zero errors from OJB =(
>>>
>>> Also, do you get the same problem if you try the query via the
>>> PersistenceBroker api instead of the JDO api?
>>>
>>> -Brian
>>>
>>> On Apr 7, 2004, at 5:44 AM, Mike Ahlers wrote:
>>>
>>>> Hi,
>>>>
>>>> I am a new kid on the block and work with the OJB/JDO block. Using
>>>> a database with no relations works perfectly, however when I
>>>> increase complexity and use foreign keys I fail to get it working.
>>>> The following error is what I get:
>>>>
>>>> [org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while
>>>> iterate Result Set for query
>>>> org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from
>>>> class nl.hippo.nvpt.Articles where [id = 55], class descriptor:
>>>> nl.hippo.nvpt.Ar
>>>> ticles]
>>>> / by zero java.lang.ArithmeticException: / by zero
>>>>
>>>> Can anybody explain why iterating over a result-set gives a div by
>>>> zero?
>>>>
>>>> Thanks in advance,
>>>> Mike Ahlers
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Problem with OJB
Posted by Brian McCallister <mc...@forthillcompany.com>.
Which version of OJB are you using? Line numbers don't match up to the
one I have, which is, admittedly, cvs head -- though rc6 and cvs head
are pretty similar right now.
Okay, some try-the-common-things-first:
Try changing the PK and FK values to Integer types instead of int.
Using the primitives can really boggle OJB as it is not safe to presume
0 is equivalent to not-set (null).
Test.
Remove the "default-fetch" as it only applies to JDO rinse, repeat.
Will look at more carefully asap =)
-Brian
On Apr 7, 2004, at 9:56 AM, Mike Ahlers wrote:
> Hi Brian,
>
> I can try... let me describe what I got so far. After digging deeper
> into this and producing some relevant debug statements I find the
> following written on my console:
>
> console output:
> --- start snippet ---
> NVTPDataAccessObject2: getArticle: called with id: 56
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery
> : Query from class nl.hippo.nvpt.Articles where [id = 56]
> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
> SQL:SELECT
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
> OGIN,A0
> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT
> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE
> A0.ID = ?
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
> executeQuery: com.mysql.jdbc.PreparedStatement@13c33b7: SELECT
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.
> ID FROM ARTICLES A0 WHERE A0.ID = 56
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
> RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query:
> Query from class nl.hippo.nvpt.Articles where [id = 56], class
> descriptor: nl.hippo.nvpt.Articles]] initialized
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
> SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery
> : Query from class nl.hippo.nvpt.Articles where [type = 3]
>
>
> ^^^^^^
>
> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
> SQL:SELECT
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
> OGIN,A0
> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT
> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE
> A0.TYPE = ?
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:
> executeQuery: com.mysql.jdbc.PreparedStatement@1f8f8c8: SELECT
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L
> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.
> ID FROM ARTICLES A0 WHERE A0.TYPE = 3
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
> RsIterator[org.apache.ojb.
> broker.accesslayer.RsQueryObject[query: Query from class
> nl.hippo.nvpt.Articles where [type = 3], class descriptor:
> nl.hippo.nvpt.Articles]] initialized
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> ...
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() ->
> false
> java.lang.ArithmeticException: / by zero
> at
> org.apache.ojb.broker.accesslayer.BasePrefetcher.<init>(BasePrefetcher.
> java:115)
> at
> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.<init>(Rel
> ationshipPrefetcherImpl.java:78)
> at
> org.apache.ojb.broker.accesslayer.CollectionPrefetcher.<init>(Collectio
> nPrefetcher.java:97)
> at
> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createR
> elationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Q
> ueryReferenceBroker.java:315)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
> eryReferenceBroker.java:185)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
> eryReferenceBroker.java:242)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu
> eryReferenceBroker.java:262)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(Quer
> yReferenceBroker.java:513)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(Que
> ryReferenceBroker.java:695)
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(Persistenc
> eBrokerImpl.java:1153)
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(
> PersistenceBrokerImpl.java:1217)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.getReferencedObject(Que
> ryReferenceBroker.java:478)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReference(Query
> ReferenceBroker.java:358)
> at
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReferences(Quer
> yReferenceBroker.java:400)
> at
> org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsI
> terator.java:501)
> at
> org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293)
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Persi
> stenceBrokerImpl.java:1298)
> at
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery
> (DelegatingPersistenceBroker.java:291)
> at
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery
> (DelegatingPersistenceBroker.java:291)
> at nl.hippo.nvpt.NVTPDataAccessObject2.getArticle(Unknown
> Source)
> --- end snippet ---
>
> Note the sudden 'translation' of 'Article_types' into 'Articles'. I am
> expecting a query like: Query from class nl.hippo.nvpt.Article_types
> where [type = 3] and not Query from class nl.hippo.nvpt.Articles where
> [type = 3]. Could this a bug in the SqlGeneratorDefaultImpl regarding
> nested queries? Anyways, this is what I am trying to map:
>
> repository.xml:
> --- start snippet ---
> <class-descriptor class="nl.hippo.nvpt.Articles" table="ARTICLES">
> <field-descriptor name="id" primarykey="true" default-fetch="true"
> column="ID" jdbc-type="INTEGER"/>
> <field-descriptor name="type" default-fetch="true" column="TYPE"
> jdbc-type="INTEGER"/>
> ....
> <reference-descriptor name="article_types"
> class-ref="nl.hippo.nvpt.Article_types" auto-update="false"
> auto-delete="false">
> <foreignkey field-ref="type"/>
> </reference-descriptor>
> </class-descriptor>
> --- end snippet ---
>
> The following classes are generated (like the repository.xml) by Druid
> and has setters and getters.
>
> Articles.java:
> --- start snippet ---
> public class Articles {
> public int id;
> public int type;
> public Article_types article_types;
> ...
> }
> --- end snippet ---
>
> Article_types:
> --- start snippet ---
> public class Article_types
> {
> public int id;
> public String naam;
> public String omschrijving;
> }
> --- end snippet ---
>
> My data access object looks like this:
> --- start snippet ---
> public Articles getArticle(int id) {
> ...
> System.out.println("NVTPDataAccessObject2: getArticle: called with id:
> " + id);
> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> // Create criteria
> criteria = new Criteria();
> criteria.addEqualTo("id", new Integer(id)); // Refine
> criteria
> // Create query
> query = new QueryByCriteria(Articles.class, criteria);
> result = (Articles) broker.getObjectByQuery(query);
> ...
> return result;
> --- end snippet ---
>
> Brian McCallister wrote:
>
>> Any chance you can post the relevent repository_user.xml snippets and
>> an outline at least of what they map to? More than happy to help you
>> work out what's going on =)
>>
>> I have never seen divide by zero errors from OJB =(
>>
>> Also, do you get the same problem if you try the query via the
>> PersistenceBroker api instead of the JDO api?
>>
>> -Brian
>>
>> On Apr 7, 2004, at 5:44 AM, Mike Ahlers wrote:
>>
>>> Hi,
>>>
>>> I am a new kid on the block and work with the OJB/JDO block. Using a
>>> database with no relations works perfectly, however when I increase
>>> complexity and use foreign keys I fail to get it working. The
>>> following error is what I get:
>>>
>>> [org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while
>>> iterate Result Set for query
>>> org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from
>>> class nl.hippo.nvpt.Articles where [id = 55], class descriptor:
>>> nl.hippo.nvpt.Ar
>>> ticles]
>>> / by zero java.lang.ArithmeticException: / by zero
>>>
>>> Can anybody explain why iterating over a result-set gives a div by
>>> zero?
>>>
>>> Thanks in advance,
>>> Mike Ahlers
>>>
>>>
>>
>>
>>
>
>
>
Re: Problem with OJB
Posted by Mike Ahlers <mi...@hippo.nl>.
Hi Brian,
I can try... let me describe what I got so far. After digging deeper
into this and producing some relevant debug statements I find the
following written on my console:
console output:
--- start snippet ---
NVTPDataAccessObject2: getArticle: called with id: 56
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery :
Query from class nl.hippo.nvpt.Articles where [id = 56]
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.LOGIN,A0
.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID
FROM ARTICLES A0 WHERE A0.ID = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery:
com.mysql.jdbc.PreparedStatement@13c33b7: SELECT
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.LOGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID
FROM ARTICLES A0 WHERE A0.ID = 56
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query
from class nl.hippo.nvpt.Articles where [id = 56], class descriptor:
nl.hippo.nvpt.Articles]] initialized
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery :
Query from class nl.hippo.nvpt.Articles where [type = 3]
^^^^^^
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.LOGIN,A0
.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID
FROM ARTICLES A0 WHERE A0.TYPE = ?
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery:
com.mysql.jdbc.PreparedStatement@1f8f8c8: SELECT
A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.LOGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID
FROM ARTICLES A0 WHERE A0.TYPE = 3
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:
RsIterator[org.apache.ojb.
broker.accesslayer.RsQueryObject[query: Query from class
nl.hippo.nvpt.Articles where [type = 3], class descriptor:
nl.hippo.nvpt.Articles]] initialized
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
...
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
[org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> false
java.lang.ArithmeticException: / by zero
at
org.apache.ojb.broker.accesslayer.BasePrefetcher.<init>(BasePrefetcher.java:115)
at
org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.<init>(RelationshipPrefetcherImpl.java:78)
at
org.apache.ojb.broker.accesslayer.CollectionPrefetcher.<init>(CollectionPrefetcher.java:97)
at
org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createRelationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
at
org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryReferenceBroker.java:315)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:185)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:242)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:262)
at
org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:513)
at
org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:695)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1153)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(PersistenceBrokerImpl.java:1217)
at
org.apache.ojb.broker.core.QueryReferenceBroker.getReferencedObject(QueryReferenceBroker.java:478)
at
org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReference(QueryReferenceBroker.java:358)
at
org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReferences(QueryReferenceBroker.java:400)
at
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:501)
at
org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(PersistenceBrokerImpl.java:1298)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(DelegatingPersistenceBroker.java:291)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(DelegatingPersistenceBroker.java:291)
at nl.hippo.nvpt.NVTPDataAccessObject2.getArticle(Unknown Source)
--- end snippet ---
Note the sudden 'translation' of 'Article_types' into 'Articles'. I am
expecting a query like: Query from class nl.hippo.nvpt.Article_types
where [type = 3] and not Query from class nl.hippo.nvpt.Articles where
[type = 3]. Could this a bug in the SqlGeneratorDefaultImpl regarding
nested queries? Anyways, this is what I am trying to map:
repository.xml:
--- start snippet ---
<class-descriptor class="nl.hippo.nvpt.Articles" table="ARTICLES">
<field-descriptor name="id" primarykey="true" default-fetch="true"
column="ID" jdbc-type="INTEGER"/>
<field-descriptor name="type" default-fetch="true" column="TYPE"
jdbc-type="INTEGER"/>
....
<reference-descriptor name="article_types"
class-ref="nl.hippo.nvpt.Article_types" auto-update="false"
auto-delete="false">
<foreignkey field-ref="type"/>
</reference-descriptor>
</class-descriptor>
--- end snippet ---
The following classes are generated (like the repository.xml) by Druid
and has setters and getters.
Articles.java:
--- start snippet ---
public class Articles {
public int id;
public int type;
public Article_types article_types;
...
}
--- end snippet ---
Article_types:
--- start snippet ---
public class Article_types
{
public int id;
public String naam;
public String omschrijving;
}
--- end snippet ---
My data access object looks like this:
--- start snippet ---
public Articles getArticle(int id) {
...
System.out.println("NVTPDataAccessObject2: getArticle: called with id: "
+ id);
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
// Create criteria
criteria = new Criteria();
criteria.addEqualTo("id", new Integer(id)); // Refine criteria
// Create query
query = new QueryByCriteria(Articles.class, criteria);
result = (Articles) broker.getObjectByQuery(query);
...
return result;
--- end snippet ---
Brian McCallister wrote:
> Any chance you can post the relevent repository_user.xml snippets and
> an outline at least of what they map to? More than happy to help you
> work out what's going on =)
>
> I have never seen divide by zero errors from OJB =(
>
> Also, do you get the same problem if you try the query via the
> PersistenceBroker api instead of the JDO api?
>
> -Brian
>
> On Apr 7, 2004, at 5:44 AM, Mike Ahlers wrote:
>
>> Hi,
>>
>> I am a new kid on the block and work with the OJB/JDO block. Using a
>> database with no relations works perfectly, however when I increase
>> complexity and use foreign keys I fail to get it working. The
>> following error is what I get:
>>
>> [org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while
>> iterate Result Set for query
>> org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from
>> class nl.hippo.nvpt.Articles where [id = 55], class descriptor:
>> nl.hippo.nvpt.Ar
>> ticles]
>> / by zero java.lang.ArithmeticException: / by zero
>>
>> Can anybody explain why iterating over a result-set gives a div by zero?
>>
>> Thanks in advance,
>> Mike Ahlers
>>
>>
>
>
>
Re: Problem with OJB
Posted by Brian McCallister <br...@apache.org>.
Any chance you can post the relevent repository_user.xml snippets and
an outline at least of what they map to? More than happy to help you
work out what's going on =)
I have never seen divide by zero errors from OJB =(
Also, do you get the same problem if you try the query via the
PersistenceBroker api instead of the JDO api?
-Brian
On Apr 7, 2004, at 5:44 AM, Mike Ahlers wrote:
> Hi,
>
> I am a new kid on the block and work with the OJB/JDO block. Using a
> database with no relations works perfectly, however when I increase
> complexity and use foreign keys I fail to get it working. The
> following error is what I get:
>
> [org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while
> iterate Result Set for query
> org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from
> class nl.hippo.nvpt.Articles where [id = 55], class descriptor:
> nl.hippo.nvpt.Ar
> ticles]
> / by zero java.lang.ArithmeticException: / by zero
>
> Can anybody explain why iterating over a result-set gives a div by
> zero?
>
> Thanks in advance,
> Mike Ahlers
>
>