Re: Like keyword not keeping format

Buck,

Thanks for the good advice as always.
These are new files which I created and there has only ever been one
version of those columns.
No other definitions for those fields in the program.

DSPFFD File1 shows:
Data Field Buffer
Field Type Length Length
UNIQUEID BINARY 9 0 4

DSPFFD File2 shows:
Data Field Buffer
Field Type Length Length
MESSAGEID BINARY 9 0 4

But interestingly in the Cross Reference:
UNIQUEID 124 INTEGER PRECISION(10,0) IN AFTER
MESSAGEID 213 INTEGER PRECISION(9,0) COLUMN
(NOT NULL)

The first coming from the ExtName DS and the second from the embedded SQL.

However, I'm not seeing the message in the log now after a few
recompilations so I think I need to investigate a bit more before I waste
any more of people's time.

Thanks kindly:
Craig



On 19 February 2018 at 16:47, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 19 February 2018 at 11:19, Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:

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

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

-snip

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

Is the file being read and the file being updated the same files that
the compiler used? (Rule zero: check the library list)
What does the compiler listing cross reference say about the fields?
In particular, are there multiple definitions of either MESSAGEID or
UNIQUEID? Sub-procedure differs from main? (Rule one: trust the
compiler)
Is the program checking SQLSTATE after the INSERT/UPDATE? If so, is
there a deliberate reason to skip warnings like this?

I find some of these SQL errors hard to diagnose because there can be
multiple columns that have issues, and there's just one generic
SQLSTATE telling me that something went awry. It gets particularly
ugly when stored procedures, triggers, UDFs, and views of views are
involved. Is this particular program a simple TABLE to TABLE update
with no other Db2 functionality? I've scoured TRIGGER1 for hours when
it was really TRIGGER2 that had the issue. Doh!
--buck
--
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.