Re: SQL Precompiler Issues on V5R3

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

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