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



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.