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



It is not clear what you mean by SQL data structure. SQL generates several.

I have been writing RPG programs with Procedures and SQL for at least 15
years and have no problems having opens in one procedure and a fetch in
another and a fetch prior in another.

SQL generates several data structures. First it generates the SQLCA(Sql
Communications Area) which is always global and can be accessed anywhere.
All the fields names are documented.

In addition, the SQL pre-compiler generates a data structure for each SQL
operation in each procedure that is used to pass the data to the router
with a Call.

What I don't understand is you say you want to access these structures in
another procedures. You cannot access them in procedure they are created.
They are for IBM use and you don't know even what they are going to name
the fields in data structures so why you would want to access them from
another procedure makes no sense.

What I suspect you are talking about is data structures that you create to
receive data on a fetch. These are just normal data structures and the rule
of scope would apply them just like any other variable in a procedure. If
you declare it in a procedure, you cannot see it outside of the procedure.
If you want to do something with the data outside of the procedure you are
going to have to return it to a caller or make it global. No different than
any other variable.

Is there something else you are doing?

I could send you the code for a module that uses SQL for all I/O to load a
screen.



On Thu, May 11, 2017 at 8:16 AM, <dlclark@xxxxxxxxxxxxxxxx> wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 05/11/2017 11:12:14
AM:
I might be remembering incorrectly, but I *think* that the declare
cursor
must be in the main line, not the sub-procedure.

I always declare my cursor in a subprocedure -- but I use a single
subprocedure for OPEN, FETCH, and CLOSE processing of the related cursor.
So, if separate subprocedures are used for these three operations then,
yes, the cursor should be declared at the top of the program.

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


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.