× 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 30-Mar-2015 10:01 -0500, Jeff Young wrote:
<<SNIP>>
Given the table VARCUST, with field names RMCMP (2,0)
and RMCUST (7 A)

FWiW, stated as the DDL is much clearer, and also may be more telling; e.g. if there are long-names included and the explicit attributes beyond just [alluded] type and length:

CREATE TABLE VARCUST
( RMCMP Dec(2) not null
, RM_Customer_Id
for RMCUST Char(7) for bit data
)

and program WNCUSTEXP with parms 2,0 and 7a.

Along the same lines as the above comment, an [effective or actual] prototype would be clearer; allowing a reader to understand if the following CREATE is compatible.

create procedure WNCUSTEXP
( in DEC(02)
, char(07)
) language RPGLE
parameter style general
external name WNCUSTEXP
Procedure WNCUSTEXP was created in QGPL.

The IN is missing for the second parameter in the above CREATE. That should not be an issue however, as the IN is the default. The column-name as variable in a trigger would not be update-capable, so that is important.

create trigger varcust_ai
after insert
on varcust
referencing new as n
for each row mode db2row
begin
call WNCUSTEXP ( n.RMCMP, n.rmcust)
end
Variable RMCUST not defined or not usable.

That is [inferred to be] the msg SQL0312 aka sqlcode -312 which IIRC, would occur for reference made to the short-name for a column, if a long-name also exists; e.g. in my CREATE TABLE example, the reference to n.rmcust would have to be coded as n.RM_Customer_Id instead.

After resolving that issue, whatever the origin, the missing semicolon for the CALL will be the next issue; as a -104 syntax error.

Perhaps my original example was too simplistic, for not having recalled a valid restriction; not a big surprise, per my not being actively\often coding SQL routines, and notably trigger routine bodies. If a valid restriction is being enforced, then the issue is easily overcome by resolving the restriction by following the Recovery from the message [mentioning triggers], and that would be to "Declare the variable as an SQL variable."

I do not understand why I receiving the variable not defined
message.

I do not immediately recall such a restriction for referencing column names as IN variables on a CALL [aside from the requirement to refer only to the long-name of a column], but as noted just above, a /circumvention/ to the issue would be achieved by coding the trigger to use variables instead of the column names:

create trigger varcust_ai
after insert
on varcust
referencing new as n
for each row mode db2row
begin
declare rm_comp dec(2) ;
declare rm_cust char(7) ;
set rm_comp = n.RMCMP ;
set rm_cust = n.RMCUST ;
call WNCUSTEXP ( rm_comp, rm_cust ) ;
end


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.