«

I have a simple Oracle (10g) query with a simple where clause, and no
joins. When I run that query in SQuirreL, it gives me the 8 records
that I expect. When I run that query in a Java application running in
WebLogic 10.1, the "while" loop calling "rs.next()" returns all 8
records twice, making it seem like there were 16 records.

I use "setFetchSize(20)" on the statement. I used to use "AND ROWNUM
<= 20". Both produce the same result. I originally didn't have
"SELECT DISTINCT ...", but I tried adding that. Still no difference.

Is there something obvious that could be causing this?

The query is very simple. It just looks like this, with most of the
column names removed, and the table name changed:

SELECT ID, ... FROM TABLE_NAME tn WHERE tn.CREATION_DATE = ?

The somewhat elided code for the loop looks like this:

--------------------------
try {
rs = getRecords(connection);

// Indicates whether at least one row was found.
boolean foundOne = false;

while (rs.next()) {
foundOne = true;
final Record record = makeRecord(rs); // makeRecord() just has a bunch
of "getString()" calls on the rs.
processRecord(record, counters);
++ recordsProcessed;
}

if (!foundOne) {
break;
}

if (overTimeBudget(startTime)) {
break;
}

logInfo("Processed " + recordsProcessed + " record" +
(recordsProcessed == 1 ? "" : "s") + " so far.");
}
--------------------------

What could be going wrong here?

On Wed, 12 Aug 2009 11:39:37 -0700 (PDT), "david.karr"
<> wrote, quoted or indirectly quoted
someone who said :

>What could be going wrong here?

see http://mindprod.com/jgloss/sscce.html

We need to see the details.

see http://mindprod.com/jgloss/iterator.html
to make sure you know precisely how they work.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"You can have quality software, or you can have pointer arithmetic; but you cannot have both at the same time."
~ Bertrand Meyer (born: 1950 age: 59) 1989, creator of design by contract and the Eiffel language.

On Aug 12, 12:59*pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> On Wed, 12 Aug 2009 11:39:37 -0700 (PDT), "david.karr"
> <davidmichaelk...@gmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
> >What could be going wrong here?
>
> seehttp://mindprod.com/jgloss/sscce.html
>
> We need to see the details.

I'm not sure what else I can provide. A fully working (or failing, as
the case might be) example would be pretty unlikely.

The only other directly relevant code is the "makeRecord()" method,
which is approximately this:

-------------
private Record makeRecord(final ResultSet rs)
throws SQLException {

Record record = new Record();

record.id = trimOrNull(rs.getString(1));
.
.
.
record.creationDate = rs.getDate(21);
record.maskAddress = trimOrNull(rs.getString(22));
record.badAddress = rs.getInt(24);
record.unitType = trimOrNull(rs.getString(25));
.
.
.
record.badRecord = rs.getInt(31);

logInfo("Returning record [" + record.id + "]");

return (record);
}

private String trimOrNull(String str) {
return (str != null ? str.trim() : null);
}
---------------

David Karr wrote :
> On Aug 12, 12:59*pm, Roedy Green <see_webs...@mindprod.com.invalid>
> wrote:
>> On Wed, 12 Aug 2009 11:39:37 -0700 (PDT), "david.karr"
>> <davidmichaelk...@gmail.com> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>> What could be going wrong here?
>>
>> seehttp://mindprod.com/jgloss/sscce.html
>>
>> We need to see the details.
>
> I'm not sure what else I can provide. A fully working (or failing, as
> the case might be) example would be pretty unlikely.
>
> The only other directly relevant code is the "makeRecord()" method,
> which is approximately this:
>
> -------------
> private Record makeRecord(final ResultSet rs)
> throws SQLException {
>
> Record record = new Record();
>
> record.id = trimOrNull(rs.getString(1));

You should use getters and setters, so the above would be:
record.setID( trimOrNull(rs.getString(1)) );

>
> logInfo("Returning record [" + record.id + "]");

and:
logInfo("Returning record [" + record.getID() + "]");

>
> return (record);
> }
>
> private String trimOrNull(String str) {
> return (str != null ? str.trim() : null);
> }

This is an expensive way of doing it. Trim the value before you store
it, then just retrieve it.

You did not say HOW the records were duplicated:

1
1
2
2
3
3
4
4

or

1
2
3
4
1
2
3
4

--
Wojtek

On Aug 12, 5:14*pm, Wojtek <nowh...@a.com> wrote:
> David Karr wrote :
>
>
>
> > On Aug 12, 12:59*pm, Roedy Green <see_webs...@mindprod.com.invalid>
> > wrote:
> >> On Wed, 12 Aug 2009 11:39:37 -0700 (PDT), "david.karr"
> >> <davidmichaelk...@gmail.com> wrote, quoted or indirectly quoted
> >> someone who said :
>
> >>> What could be going wrong here?
>
> >> seehttp://mindprod.com/jgloss/sscce.html
>
> >> We need to see the details.
>
> > I'm not sure what else I can provide. *A fully working (or failing, as
> > the case might be) example would be pretty unlikely.
>
> > The only other directly relevant code is the "makeRecord()" method,
> > which is approximately this:
>
> > -------------
> > private Record makeRecord(final ResultSet rs)
> > * * throws SQLException {
>
> > * * Record *record *= new Record();
>
> > * * record.id * * * * * * = trimOrNull(rs.getString(1));
>
> You should use getters and setters, so the above would be:
> * * *record.setID( trimOrNull(rs.getString(1)) );

Does this have any relevance to the problem?

> > private String trimOrNull(String str) {
> > * * return (str != null ? str.trim() : null);
> > }
>
> This is an expensive way of doing it. Trim the value before you store
> it, then just retrieve it.

Actually, I realized it has to be a little more complicated than
that. I have to set it to null if the string is empty or nothing but
blanks. My current method implements that, but this is also
irrelevant to the problem.

> You did not say HOW the records were duplicated:
>
> 1
> 1
> 2
> 2
> 3
> 3
> 4
> 4
>
> or
>
> 1
> 2
> 3
> 4
> 1
> 2
> 3
> 4

The latter.

The other interesting detail is that I don't see this happen all the
time, even when it's retrieving the exact same set of records. My
current test case has 7 particular records. Sometimes it correctly
returns only the 7 records, sometimes it starts over again after the
7th, retrieving 1-7 again.

David Karr wrote:
> On Aug 12, 5:14 pm, Wojtek <nowh...@a.com> wrote:
>> David Karr wrote :
>>
>>
>>
>>> On Aug 12, 12:59 pm, Roedy Green <see_webs...@mindprod.com.invalid>
>>> wrote:
>>>> On Wed, 12 Aug 2009 11:39:37 -0700 (PDT), "david.karr"
>>>> <davidmichaelk...@gmail.com> wrote, quoted or indirectly quoted
>>>> someone who said :
>>>>> What could be going wrong here?
>>>> seehttp://mindprod.com/jgloss/sscce.html
>>>> We need to see the details.
>>> I'm not sure what else I can provide. A fully working (or failing, as
>>> the case might be) example would be pretty unlikely.
>>> The only other directly relevant code is the "makeRecord()" method,
>>> which is approximately this:
>>> -------------
>>> private Record makeRecord(final ResultSet rs)
>>> throws SQLException {
>>> Record record = new Record();
>>> record.id = trimOrNull(rs.getString(1));
>> You should use getters and setters, so the above would be:
>> record.setID( trimOrNull(rs.getString(1)) );
>
> Does this have any relevance to the problem?
>
>>> private String trimOrNull(String str) {
>>> return (str != null ? str.trim() : null);
>>> }
>> This is an expensive way of doing it. Trim the value before you store
>> it, then just retrieve it.
>
> Actually, I realized it has to be a little more complicated than
> that. I have to set it to null if the string is empty or nothing but
> blanks. My current method implements that, but this is also
> irrelevant to the problem.
Look into commons-lang, they have a nifty class with a nice static method:
org.apache.commons.lang.StringUtils.trimToNull(Str ing )
<http://commons.apache.org/lang/apidocs/org/apache/commons/lang/StringUtils.html#trimToNull(java.lang.String)>
Yes, you *can* write the code yourself, but why bother? Not to mention
there are a lot of other nifty classes and methods in that library
>
>> You did not say HOW the records were duplicated:
>>
>> 1
>> 1
>> 2
>> 2
>> 3
>> 3
>> 4
>> 4
>>
>> or
>>
>> 1
>> 2
>> 3
>> 4
>> 1
>> 2
>> 3
>> 4
>
> The latter.
>
> The other interesting detail is that I don't see this happen all the
> time, even when it's retrieving the exact same set of records. My
> current test case has 7 particular records. Sometimes it correctly
> returns only the 7 records, sometimes it starts over again after the
> 7th, retrieving 1-7 again.

Sounds like the problem is on line 42 of the file you didn't show us.
In other words, we can't help you unless you can provide an SSCCE. Over
half of the benefit from constructing an SSCCE is in the process of
constructing it. You may find that you have done something silly, or
that its not actually happining the way you suspect. At the very
least, I would add some kind of logging to your while loop, to test
whether you're actually going through the result-set twice, or if the
result-set is twice as long as it should be.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:
> Look into commons-lang, they have a nifty class with a nice static method:
> org.apache.commons.lang.StringUtils.trimToNull(Str ing )
> <http://commons.apache.org/lang/apidocs/org/apache/commons/lang/StringUtils.html#trimToNull(java.lang.String)>
>
> Yes, you *can* write the code yourself, but why bother? Not to mention

Because it's only a one-liner and it avoids pulling in a whole library that
has at least one major bug that it has refused to fix.

> there are a lot of other nifty classes and methods in that library

Including their version of type-safe enumeration that has a nasty bug in it
for Java 5 and later.

--
Lew

David Karr wrote :
> On Aug 12, 5:14*pm, Wojtek <nowh...@a.com> wrote:
>> David Karr wrote :
>> You should use getters and setters, so the above would be:
>> * * *record.setID( trimOrNull(rs.getString(1)) );
>
> Does this have any relevance to the problem?

Nope. But it illustratess good OOP practice.

>> You did not say HOW the records were duplicated:
>>
>> 1
>> 1
>> 2
>> 2
>> 3
>> 3
>> 4
>> 4
>>
>> or
>>
>> 1
>> 2
>> 3
>> 4
>> 1
>> 2
>> 3
>> 4
>
> The latter.
>
> The other interesting detail is that I don't see this happen all the
> time, even when it's retrieving the exact same set of records. My
> current test case has 7 particular records. Sometimes it correctly
> returns only the 7 records, sometimes it starts over again after the
> 7th, retrieving 1-7 again.

One of the things about code is that it does not change over time by
itself, ie it does not rust. It is impossible for the same code with
the same data to return different results.

Have you tried setting a conditional breakpoint? One that only breaks
when the counter reaches a value which is one over the expected number
of records? Then you can view the variable conditions and see what just
happened.

--
Wojtek

On Aug 12, 11:39*am, "david.karr" <davidmichaelk...@gmail.com> wrote:
> I have a simple Oracle (10g) query with a simple where clause, and no
> joins. When I run that query in SQuirreL, it gives me the 8 records
> that I expect. When I run that query in a Java application running in
> WebLogic 10.1, the "while" loop calling "rs.next()" returns all 8
> records twice, making it seem like there were 16 records.

Never mind. Dumb mistake. It wasn't an Oracle problem. The problem
was truly present in code that wasn't shown here, as the code doing
the query was executed in a loop, because of an earlier design
decision.

Lew wrote:
> Daniel Pitts wrote:
>> Look into commons-lang, they have a nifty class with a nice static
>> method:
>> org.apache.commons.lang.StringUtils.trimToNull(Str ing )
>> <http://commons.apache.org/lang/apidocs/org/apache/commons/lang/StringUtils.html#trimToNull(java.lang.String)>
>>
>> Yes, you *can* write the code yourself, but why bother? Not to mention
>
> Because it's only a one-liner and it avoids pulling in a whole library
> that has at least one major bug that it has refused to fix.
>
>> there are a lot of other nifty classes and methods in that library
>
> Including their version of type-safe enumeration that has a nasty bug in
> it for Java 5 and later.
>
On noes, there is a Bug in one infrequently used piece of my operating
system. Time to shut down the computer and throw it out the window.

WHAT!?

There are still many useful methods in there, and it isn't worth
throwing the whole thing out because of one bug. Otherwise *nothing*
would be worth using (save maybe TeX )

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>