× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Mark

My interest is in knowing how many rows I will need to process from the OPEN or PREPARE - but as you say, if something changes, not so good.

I wasn't so much interested in how many were returned from a fetch with rows specified - that, though, is very useful. Is it too messy to have an outer loop that checks the other SQLERRD element that says the number returned is less than you requested?

Just brainstorming!

In some scenarios it is easier to code with a known count - but it has to be a scenario where things won't change, it seems.

Maybe it's a matter of trying to get by with less work - there's a word for that! But even SELECT COUNT(*) isn't reliable enough, OK, gotta do the work!

Later
Vern

On 9/15/2015 11:02 AM, Mark Murphy/STAR BASE Consulting Inc. wrote:
In my testing, DB2_NUMBER_ROWS is not reliable for looping as it does not try to tell you how many rows are available. I use something like this:

dcl-s rowcnt Int(10) Inz(50);
dcl-s recsread Int(10) Inz(0);
dcl-ds ary LikeDs(record_t) Dim(50) Inz;

dou recsread < rowcnt;
exec sql
fetch C1 for :rowcnt rows into :ary;
select;
with %subst(sqlstate:1:2) > '02';
exec sql get diagnostics condition 1
:message = message_txt;
SndSqlMsg(message);
other;
exec sql get diagnostics
:recsread = row_count;
endsl;

... do something with record

enddo;


Get diagnostics ROW_COUNT is reliable for looping as it tells you exactly how many records the fetch returned. If you got less than you asked for, then you got them all. If you got the number you asked for, then there might be more available. ROW_COUNT will never be more than what you asked for.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----Charles Wilt <charles.wilt@xxxxxxxxx> wrote: -----
To: "RPG programming on the IBM i (AS/400 and iSeries)" <rpg400-l@xxxxxxxxxxxx>
From: Charles Wilt <charles.wilt@xxxxxxxxx>
Date: 09/15/2015 09:09AM
Subject: Re: Loading arrayDS from sql select into statement?

Just note that if using a SENSITIVE cursor, the number of rows you get with
the SELECT COUNT may not equal the number of rows fetched.

If you specify an INSENSITIVE cursor, then the count should match since the
system copies the data to temp storage. Unless somebody adds a row between
the SELECT COUNT and the OPEN of the cursor.

The default for cursors is ASENSITIVE, which means you could end up with
either SENSITIVE or INSENSITIVE.

Charles

On Tue, Sep 15, 2015 at 9:03 AM, Koester, Michael <mkoester@xxxxxxxxxxxxx>
wrote:

Vern/Marvin/Charles,
I was intrigued by the idea of GET DIAGNOSTICS, but at least for my
current needs, I too tend to favor opening the process with a "select
count(*) into..."
With that, I can wrap the whole "declare cursor", "open cursor", "fetch
into", and "close cursor" in an "if countOfRows > 0" structure, thereby not
executing unnecessary code when there are no array rows to be loaded.

While this particular need does not require trimming nanoseconds, I was
just looking for "best practices" ideas that would enhance my coding, now
and future.

Michael Koester

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Vernon
Hamberg
Sent: Monday, September 14, 2015 5:18 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: RPG400-L Digest, Vol 14, Issue 336

Marvin

I thought this was an estimate only for the OPEN - much the same as
SQLERRD(3) which is documented like this for the PREPARE -

For the PREPARE statement, contains the estimated number of rows
selected. If the number of rows is greater than 2 147 483 647, then 2
147 483 647 is returned.

There've been other threads about this, and I think it has been said the
only sure way to get row count is SELECT COUNT(*) FROM TABLE

Now I'm very happy to be mistaken here, because I'd love to have the
simple answer from time to time, the SQLERRD(3) answer. Or the GET
DIAGNOSTICS answer - oh, that array element IS updated with the number or
rows retrieved with FETCH - useful for multiple-row fetches.

I do see that the documentation for DB2_NUMBER_ROWS says it IS the number
of rows after an OPEN or FETCH, but with a SENSITIVE cursor it is an
estimate. I see that default for SENSITIVE on a cursor is ASENSITIVE, so
that what you get depends.

Any takers on whether the GET DIAGNOSTICS value is reliable for managing
a
loop? Under what conditions?

Regards
Vern

On 9/14/2015 2:43 PM, Marvin Radding wrote:
Mitch,

There is one method that would be a short cut. GET DIAGNOSTICs can
provide the total number of records in the data set after the open. That
can control the number of records fetched in the FETCH INTO statement.
After the open you can code:

/exec sql
GET DIAGNOSTICS :row_count = DB2_NUMER_ROWS; /end


Marvin

------------------------------

message: 8
date: Mon, 14 Sep 2015 18:17:00 +0000 (UTC)
from: Mitch Gallman <qtemp@xxxxxxx>
subject: Re: Loading arrayDS from sql select into statement?

I've used the following article several times as a reference:
http://www.itjungle.com/fhg/fhg052009-story01.html
I've never had to do a select count prior to doing the fetch.
Mitch


On Monday, September 14, 2015 1:58 PM, "Koester, Michael"
<mkoester@xxxxxxxxxxxxx> wrote:

Charles,

Would be nice if you could use SELECT INTO along with FETCH FIRST XX
ROWS...
After getting the count (select count(*) into :resultCount from...),
and
declaring and opening a cursor, I can successfully use
? ? exec sql
? ? fetch MyCursor for :resultCount rows
? ? ? into :ArrayDS;
? ? ? ? ? ? ? ? ? ? ? ?
But there apparently are no shorter shortcuts.

Michael Koester
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.