× 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.



Yeah, that's exactly what I said, too - now I've had occasions to use some kind of count to control a loop, but it's better to use an EOF test, I think.

On 9/15/2015 7:58 AM, Charles Wilt wrote:
For SQLERRD(3), the manual says
For a FETCH statement, SQLERRD(3) contains the number of rows
fetched.

For GET DIAGNOSTICS DB2_NUMBER_ROWS
If the previous SQL statement was an OPEN or a FETCH which caused the
size of the result table to be known, returns the number of rows in the
result
table. For SENSITIVE cursors, this value can be thought of as an
approximation since rows inserted and deleted will affect the next
retrieval of
this value. Otherwise, the value zero is returned.

I don't think I'd use it to control a loop, given that the default for a
cursor is ASENSITIVE; meaning you don't care rather you get a SENSITIVE or
INSENSITIVE cursor. If you get a SENSITIVE one, then the GET DIAG is just
an estimate. I also wouldn't want to regularly force an INSENSITIVE (ie.
the data gets copied) cursor just to get a real number.


Charles



On Mon, Sep 14, 2015 at 5:18 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

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
Notice: This e-mail transmission may contain information that is
proprietary, privileged and/or confidential and is intended exclusively for
the person(s) to whom it is addressed. This message may also contain
Protected Health Information (PHI) and must be treated confidentially and
handled in accordance with HIPAA and other federal and state privacy laws.
Any use, copying, retention or disclosure by any person other than the
intended recipient or the intended recipient's designees is strictly
prohibited. If you are not the intended recipient or their designee, please
notify the sender immediately and delete this e-mail (and any accompanying
attachments).

--
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.