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



On Wed, 2004-08-25 at 10:06, Joel Cochran wrote:
> Wouldn't you want to avoid this though?  You would have to ensure that
> the local variable name is unique, which kind of defeats the purpose of
> making it local... although, back to my other statements about
> guaranteed initialization and similar items, I guess I can see a benefit
> to this.  In fact, this could come in very handy when using columnar
> functions and such for calculations... hmmm... now you've got me
> thinking...

OK, stop the presses... I just tested the following code and it worked:

0000.01 d subProc         pr
0000.02 d zip             s              5a   inz('22980')
0000.03
0000.04  /free
0000.05    subProc();
0000.06    *inlr = *on ;
0000.07  /end-free
0000.08
0000.09 p subProc         b
0000.10 d subProc         pi
0000.11
0000.12 d zip             s              5a   inz('24401')
0000.13 d zipDS         e ds                  extname(allvazips)
0000.14 d sqlStatement    s            200a   varying
0000.15 d                                     inz( 'select * +
0000.16 d                                     from allvazips +
0000.17 d                                     where zipcode = ?' )
0000.18
0001.00 c/exec sql
0002.00 c+  declare zipCursor cursor
0002.01 c+      for zipStatement
0004.00 c/end-exec   
0004.01 c/exec sql
0004.02 c+  prepare zipStatement
0004.03 c+     from :sqlStatement
0004.04 c/end-exec
0004.05 c/exec sql
0004.06 c+  open zipCursor
0004.07 c+   using :zip
0004.08 c/end-exec
0004.09 c/exec sql
0004.10 c+  fetch next from zipCursor
0004.11 c+   into :zipDS
0004.12 c/end-exec
0008.01 c/exec sql
0008.02 c+  close zipCursor
0008.04 c/end-exec
0008.05  /free
0008.06    return ;  
0008.07  /end-free
0009.00 p subProc         e

Notice that "zip" is defined both globally AND locally and it still
works!  So now I have to question the ability to use local variables in
SQL entirely... is there a case where I canNOT use a local variable in
an SQL statement?

Joel
http://www.rpgnext.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.