Re: SQLRPGLE - can I have two cursors open at the same time?

How did we get to critiquing code? The question was can it be done, not
about style or preference.

Sure, my suggestion was lazy in just checking the SQLCODE. It was after
all, proof of concept and to show what to watch for. If you really want
to go all out, maybe examples of using the Get Diagnostics should be in all
of our code too.

The point is, there are many ways to do things. I prefer to see the code
up front, rather than have to jump to line 3000, to go see what is
happening. That is not to say that I do not use procedures or
subprocedures. I absolutely do, just not for reads or fetches.


On Fri, Apr 19, 2019 at 12:14 AM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

Though... you’re not really dealing with the same obstacle in RLA as
%eof’s can (SHOULD) be conditioned by the filename. Nonetheless the
separate procedures does wonders for readability.

Jay

On Apr 18, 2019, at 11:44 PM, Roger Harman <roger.harman@xxxxxxxxxxx>

wrote:

I would absolutely agree with this. SQL or RPG.

I have an RPG program with about 8 level breaks and each level/loop is

its' own nice compact procedure. Using %KDS(kdsName : KeyCount) makes it
an absolute piece of cake. Very readable.

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf

Of Jay Vaughn

Sent: Thursday, April 18, 2019 3:36 PM
To: RPG programming on IBM i
Subject: Re: SQLRPGLE - can I have two cursors open at the same time?

Guys... prevent the sqlcode handling issue by calling a subprocedure

with your second loop In it.

Then that second sqlcode is encapsulated within its own procedure.
I think two loops nested together in same procedure is horrid... and a

bit lazy.

Jay

On Apr 18, 2019, at 6:02 PM, dlclark@xxxxxxxxxxxxxxxx wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on 04/18/2019
04:45:24 PM:

On Thu, Apr 18, 2019 at 3:39 PM Michael Schutte <mschutte369@xxxxxxxxx

wrote:

The positioning of your fetch is important.
When you get to the bottom EndDo and go back to the top, the SQLCODE

being

checked with be from your c2 fetch, not the c1. So you may exit out
prematurely.

Personally, I do primary fetches with my next fetch right before the

end.

fetch c1
Dow sqlcode = 0
open c2
fetch c2
dow sqlcode = 0
fetch c2
enddo
close c2
fetch c1
enddo

This is why priming reads are a good habit.

I don't like "priming" reads. Why? It is bad programming
practice to have the same code that does the same thing in more than

one

place in your program. There are multiple ways to avoid "priming"

reads.

One is to have custom (separate) SQLSTATE or SQLCODE variables

for

separate tables. The only way I know to do this is to use GET
DIAGNOSTICS. But, perhaps Birgitta knows of another way.

Another way is to use a procedure to perform the fetch, check the
result, and return a Boolean for the DO loop condition. For example,

see

the following psuedo-code:

open c1
dow fetch_c1_is_good()
open c2
Dow fetch_c2_is_good()
...
enddo
close c2
Enddo
close c1

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331

*********************************************************************************************

This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or

proprietary

information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and

all

copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or

privilege

is waived or lost by any error in transmission.

*********************************************************************************************

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

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxx for any subscription related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com