RE: SQL Precompiler Issues on V5R3 -- RPG400-L

Hi Vern,

I originally used and learnt SQL from MySQL and not the iSeries where it
is basically drilled in that any use of '*' is a bit of a no-no and that
has become a habit of mine. Not using '*' protects your code from any
added fields/changes in the order of fields in the underlying database
etc. This probably falls pretty squarely on the personal preference side
of things but you will probably find that outside the iSeries world any
use of '*' is frowned upon.

If that is the case with the pre-compiler I look forward to an upgrade
to V6R1... local variable scoping in embedded SQL would be a great
benefit!

Steve

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Monday, 20 December 2010 11:01 PM
To: RPG programming on the IBM i / System i
Subject: Re: SQL Precompiler Issues on V5R3

The pre-compiler required that you use different names, even in
subprocedures. I think 6.1 removed this restriction, so you could use
local variables with the same name. They did have to have the same data
type and size, I think.

The original OP used a host data structure when using SELECT * - I
wondered why he changed to using the individual elements when specifying

the separate fields - no reason to do that - just make sure the DS
matches the fields in the list.

HTH
Vern

On 12/20/2010 8:38 AM, Christen, Duane wrote:

Steve;

The 6.1 pre-compiler is leaps and bounds better than the V5R3

pre-compiler. There are still some quirks in 6.1, but in your case and
the quirks in the 6.1 pre-compiler is that they do not fully
"understand" variable scoping. I don't know how much effort Barbara(???)
and co. are putting into the pre-compiler of the future but at some
point there are diminishing returns. The pre-compiler would have to be
nearly as "smart" as the RPG compiler, not to mention Cobol and C
compilers.

I believe that Barbara, or someone on a midrange.com list, has

mentioned that the current design of the pre-compiler/compiler does not
lend itself well to handling these situations properly. I would suspect
that this won't change in the near future.

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx

[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Steven Harrison

Sent: Monday, December 20, 2010 12:39 AM
To: RPG programming on the IBM i / System i
Subject: RE: SQL Precompiler Issues on V5R3

Just as a quick follow up to anyone who might be interested. In my
module, above the procedures GetPurchaseOrder and
GetPurchaseOrderByNumber, was another procedure which also had a
parameter named 'order' of type purOrderTemplate as well. This

procedure

doesn't contain any SQL though. Moving this procedure below the
GetPurchaseOrder and GetPurchaseOrderByNumber procedures in the module
made everything compile correctly?!?

My only guess is that if you are using the same local variable names

your procedures, make sure the procedures that include SQL come before
any that don't.

To be honest I can't believe the SQL pre-compiler is as flaky as it

is.

I know we are on V5R3 but it's a bit of a shame when you have to

abandon

best programming practises to accommodate the compiler...

Cheers,

Steve

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Steven Harrison
Sent: Monday, 20 December 2010 11:34 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: SQL Precompiler Issues on V5R3

Hi All,

I'm currently stumped as to what the SQL precompiler is doing and was
wondering if anyone could shed any light on it.

I have a copy file that contains DS descriptions like below:

D purOrderTemplate...

D E DS ExtName(PURORDERS)

D Qualified

D Based(dummyPointer)

D isNew Like(Boolean)

D isDirty Like(Boolean)

D isDeleted Like(Boolean)

D isValid Like(Boolean)

I have two subprocedures called GetPurchaseOrders and
GetPurchaseOrdersByNumber.

They have a procedure interface as follows:

D GetPurchaseOrder...

D PI Like(Boolean)

D orderId
Like(purOrderTemplate.OrderId) Const

D order LikeDS(purOrderTemplate)

D lines LikeDS(purLineTemplate)

D
Dim(PURCHASE_ORDER_LINE_ARRAY_SIZE)

D numLines Like(Integer)

D sundries LikeDS(purSundryTemplate)

D
Dim(PURCHASE_ORDER_SUNDRY_ARRAY_SIZE)

D numSundries Like(Integer)

D GetPurchaseOrderByNumber...

D PI Like(Boolean)

D number

Like(purOrderTemplate.Number)

Const

D order LikeDS(purOrderTemplate)

D lines LikeDS(purLineTemplate)

D
Dim(PURCHASE_ORDER_LINE_ARRAY_SIZE)

D numLines Like(Integer)

D sundries LikeDS(purSundryTemplate)

D
Dim(PURCHASE_ORDER_SUNDRY_ARRAY_SIZE)

D numSundries Like(Integer)

If the following two procedures have the following code in them
everything compiles fine:

Exec SQL

SELECT * INTO :order FROM PurchaseOrders WHERE OrderId =
:orderId;

And

Exec SQL

SELECT * INTO :order FROM PurchaseOrders WHERE Number =
:number;

I don't want to use the '*' though so I replaced it by specifying all
the individual fields in the table in the SELECT statement and placing
them in each individual field in the DS.

Exec SQL

SELECT OrderId, Number, SupplierId, WarehouseId...

INTO :order.OrderId, :order.Number, :order.SupplierId,

:order.WhseId...

FROM PurchaseOrders

WHERE OrderId = :orderId;

Now the compile fails with an SQL0312 - Position 32 Variable ORDER not
defined or not usable... with the same error for all the fields in the
DS. Strangely, if I leave the second SQL select that compiled

correctly

as is (copying directly into the data structure with '*') it still

fails

even though I haven't made any changes to the second procedure? To
finally make things even more confusing if I declare a local DS in the
procedure such as:

D temp DS LikeDS(purOrderTemplate)

And then use this in the SQL instead of the parameter everything works
fine again??? This is driving me crazy as there seems to be no
consistency in the precompiler. I have used this style of coding in
other modules in exactly the same way with out a problem... Note: I

also

compile the SQLRPGLE with RPGPPOPT set to *LVL1.

Cheers,

Steve