Re: Loading arrayDS from sql select into statement?

For a multi-row fetch, the test for "rows returned" < "rows requested" is equivalent to testing for EOF on a single-row fetch. In fact, I do it in the same loop I would check for EOF. So I don't consider it "messy". When you are retrieving into an array, you need to know how many rows you actually fetched anyway as it may not be what you expect. Checking for EOF (sqlcode = 100 or sqlstate = '02000') will only tell you that you didn't retrieve all the rows you expected.

Back to DB2_NUMBER_ROWS, I tried to use DB2_NUMBER_ROWS in a case where I knew the number of rows wouldn't change. Made the cursor no scroll and insensitive, and still got no value for DB2_NUMBER_ROWS on open. So not real sure what the magic formula is.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote: -----
To: "RPG programming on the IBM i (AS/400 and iSeries)" <rpg400-l@xxxxxxxxxxxx>
From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Date: 09/15/2015 01:03PM
Subject: Re: Loading arrayDS from sql select into statement?

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.