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



The loop inside a loop was only to demonstrate proper error handling.

The values of SqlState exist only at the end of SQL call. Another SQL Call
resets them so you must test them at the point of the call.

The position of the cursor is maintained by cursor.

As I demonstrated, use the SqlState only to check the results of the last
call. Using it for anything else is going to get you in trouble.

The code above repeats the error of the previous post. It assumes you will
never have an SQL error where in reality they happen constantly especially
during development.




On Thu, Apr 18, 2019 at 3:36 PM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

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


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.