RE: SQLRPGLE Will Not Compile

Are you sure about that? While, in the few that I've written so
far, I always used C/Exec SQL OPEN (whatever) and then C/End-Exec on
the next line. But all of my other programs with working SQL stuff
simply use the '+' in column 7. Anyway, I put the 'C' in column six
of all of the statements; same result.

I searched "embedded SQL" in the InfoCenter (BTW, I am on V5R4) and
all it says on the subject is, "SQL statements can be placed in
detail calculations, in total calculations, or in an RPG/400
subroutine. The SQL statements are run based on the logic of the
RPG/400 statements." Which doesn't explicitly exclude
subprocedures, but, when I read that, I thought I remembered a
session at COMMON that said it was a no-no - or I was smoking some
real good stuff that day.

The compiler did bark at me regarding a couple of the field names I
was using when I had it in a subprocedure, which is why the 'PI' at
the end of some of the field names.

And a friend reminded me off-list that I could code everything in
/free, which I had forgotten. If nothing else pans out, I may try
re-keying in /free-format.

Thanks.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Friday, October 31, 2008 1:27 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: SQLRPGLE Will Not Compile

Jerry,

First off. When dealing in fix-format SQL you need the c+

So this:
C/Exec SQL
+ OPEN BidGroup
C/End-Exec

Should be:
C/Exec SQL
C+ OPEN BidGroup
C/End-Exec

Also, SQL works ok with procedures. You just have to keep in mind
that from the pre-compiler's stand point, variables declared in a
procedure are the same as globals.

As long as procedure variables seen by the pre-compiler are unique, or
if on a later release multiple instances have the same attributes, the
precompiler will be happy. Note that the restriction doesn't apply
to run-time values. In other words, the procedure variable really
isn't made global.

HTH,
Charles
On Fri, Oct 31, 2008 at 1:59 PM, Jerry Adams <Jerry@xxxxxxxxxxxxxxx>

I know this is going to turn out to be something really lame that

I'm simply missing, but bear in mind that I'm blind in one eye and
wear glasses for the other one.

I don't do much embedded SQL (yet), but I have done a few but one

I have been working on today simply will not compile. The reason
being that it does not copy in the SQL Communications area. At
first, I forgot that embedded SQL doesn't like subprocedures, but
the manual straightened me out there. But the manual said that SQL
could be embedded in either Detail or Total cals, or in a
subroutine. So I moved the necessary code to a subroutine (below).
Still no luck.

I included the pre-compiler listing, but it only had comments

about the SET Options stuff, no errors.

The only errors in the ILE RPG listing are:

*RNF7030 30 050300 The name or indicator SQL_00000 is not

*RNF7030 30 050300 The name or indicator SQL_00002 is not

<etc.>
*RNF7030 30 050300 The name or indicator SQLCA is not defined.
*RNF7030 30 054000 The name or indicator SQLCLSE is not

*RNF7030 30 052100 The name or indicator SQLCODE is not

I re-compiled an existing, working program that is very similar

(except that, being short and sweet, everything is in Deatil
calcs.), and it compiled beautifully; the compile listing shows the
SQL Communications area. I only use SQL in the one subroutine shown
below. The $Group subroutine is, for what it's worth, called by
another subroutine, which is called by another subroutine, which is
invoked from Detail calcs.

That may be too much information, but I didn't want to omit

anything that "might" have a bearing. So why is the program not
compiling? (And if you want to comment upon my code, feel free as
I'm always willing to improve.)

BEGSR $Group;
x = *Zeros;
@legend = 'Consolidation Code: ' + consCode + ' ' + @consDesc;
/end-free
C/EXEC SQL
+ SET Option
+ Naming = *Sys,
+ DatFmt = *ISO,
+ Commit = *None,
+ UsrPrf = *Owner
C/End-Exec
C/Exec SQL
+ Declare BidGroup Cursor for
+ Select
+ bqcust,
+ bqitm#,
+ bqpr,
+ bqxdat
+ from BIDQTE
+ WHERE bqcust in(SELECT arcust From ARMAST
+ WHERE arcons = :conscodePI)
+ for Read Only
C/End-Exec
C/Exec SQL
+ OPEN BidGroup
C/End-Exec
/free
DOW 1 = 1;
/end-free
C/EXEC SQL
+ FETCH Next from BidGroup
+ INTO :customerPI,:itemPI,:PricePI,:expdatePI
C/End-Exec
/free
IF sqlState = '02000'
OR sqlCode < *Zeros;
LEAVE;
ENDIF;
<do stuff with the -PI data elements>
ENDDO;
/end-free
C/EXEC SQL CLOSE BidGroup
C/end-exec

Thanks.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing

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.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing

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.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing

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.