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



Having read ( and hopefully understood ) this thread, I find myself a bit
confused about what is happening in my SQLRPGLE trigger program.
The pertinent points are:

I have two tables defined in DDL.
The first has an always generated Integer ID and the second has an Integer
into which I'm writing the ID from the first:

File1 DDL of the column:
Unique_ID for column UniqueID Integer
not Null
generated always as identity ( start with 1 increment by 1 cycle )

primary key,


File2 DDL of the column:
Message_ID for column MessageID Integer
not Null

So, both Integers.

File1 has a trigger on it and the After Image is placed in the buffer by
using this External DS and setting the pointer address:
//‚After Image
Dcl-Ds After ExtName( 'WSINQ00' ) Qualified Based( pAfter );
End-Ds;

pAfter = %Addr( TrgBuf ) + TrgBuf.NewRecOfs;

So, as far as I understand it, UniqueID in File1 and MessageID in File2 are
both type INTEGER.

The definition of the after image is based on an external name.

But when the trigger fires and I execute an SQL insert in my RPG from
After.UniqueID into MessageID I see the following message in the joblog:

Message ID . . . . . . : SQL7939 Severity . . . . . . . : 00

Message type . . . . . : Information

Date sent . . . . . . : 19/02/18 Time sent . . . . . . :
15:01:10


Message . . . . : Data conversion required on INSERT or UPDATE.

Cause . . . . . : The INSERT or UPDATE values can not be directly moved
to
the columns because the data type or length of a value is different than
one
of the columns. The INSERT or UPDATE statement ran correctly.
Performance,
however, would be improved if no data conversion was required. The
reason
data conversion is required is 2.

-- Reason 1 is that the INSERT or UPDATE value is a character or
graphic
string of a different length than column MESSAGEID.

-- Reason 2 is that the INSERT or UPDATE value is a numeric type that
is
different than the type of column MESSAGEID.

-- Reason 3 is that the INSERT or UPDATE value is a variable length
string
and column MESSAGEID is not.


I do have ExtBinInt( *Yes ) specified on the Control Spec.

I don't understand why there is conversion going on.
Am I missing something obvious?

Thanks kindly,
Craig


On 15 February 2018 at 23:05, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

On 2018-02-15 4:44 PM, Jon Paris wrote:

Thanks for the clarification Barbara - how the heck did we ever get to
such a complicated set of conditions.


Indeed.

Here's my theory on the origin of the icky rules about whether a field
defaults to zoned or packed:

RPG II only supports zoned internal variables. I think "they" wanted to
default to packed for RPG III because it was faster, but they kept
subfields in data structures as zoned because it allowed the data structure
to be viewed as text the way it worked in RPG II.

I don't know whether it would have been better or worse if the default
format for an internal field related to a file was the format that was
first encountered by the compiler. My guess is that it would have been even
worse, since it would change depending on which file was defined first. It
would be even more capricious than it is now.


--
Barbara

--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/wdsci-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.