|
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:for
"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>being
wrote:
The positioning of your fetch is important.
When you get to the bottom EndDo and go back to the top, the SQLCODE
end.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
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
separate tables. The only way I know to do this is to use GETsee
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,
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.
--questions.
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
link: https://amazon.midrange.com
Help support midrange.com by shopping at amazon.com with our affiliate
--
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
As an Amazon Associate we earn from qualifying purchases.
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.