Re: detecting "bad data" using an sql statement

However, the data currently exists in our PF's and our applications
which are 99% rpg pgms do not blow up.

Why is this?

It is not possible to insert invalid numeric data into a SQL defined table,
not even with CPYF ... *NOCHK.
On the other side it is possible to insert invalid numeric data into a DDS
described file.
There are small architectural differences between tables and physical
files,
i.e. when data is inserted in an SQL table it is checked, but it is not
checked when the data is read. If data is inserted into a DDS described
physical file, it is not checked, but it is checked when the data is read.

Since SQL does not expect invalid data (it is not possible to enter them)
it
crashes if invalid numeric data are found.

On the other side, in former times with internally described etc. it was
possible that blanks (and other invalid characters) were inserted into DDS
described tables.
So RPG and native I/O learned how to handle these invalid data.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
„Train people well enough so they can leave, treat them well enough so they
don't want to.“ (Richard Branson)


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck
Calabro
Sent: Mittwoch, 17. Januar 2018 20:43
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: detecting "bad data" using an sql statement

On 1/17/2018 11:05 AM, Jay Vaughn wrote:

However, the data currently exists in our PF's and our applications
which are 99% rpg pgms do not blow up.

Why is this?

Here, I see the following reasons:

1) Program described I / O-specs.
2) Programs compiled with IGNDECERR / FIXDECERR.
3) Not using the 'bad' column.

With RLA, if a column is RNF7031 - Unreferenced, it won't throw a decimal
data error if you CHAIN to the record. The field is, well, not referenced
by the program, and therefore the compiler doesn't try to map the database
file buffer into the (unreferenced) RPG fields. No buffer transfer, no
validation error.

With SELECT *, that same column in the same file with throw a decimal data
error. I think the database manager validates it before RPG gets to it.
This is probably over simplified, but it's a mental model that works well
enough for me to understand when I get decimal data errors and when I do
not.

--
--buck

http://wiki.midrange.com
Your updates make it better!

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD